Second argument (first in process.argv) is always ignored.

[SpacingBat3]

Current implementation of @pkgjs/parseargs assumes this to be always correct:

parseargs/index.js

Lines 69 to 70 in 6774908

	// Normally first two arguments are executable and script, then CLI arguments
	return ArrayPrototypeSlice(process.argv, 2);

However, in some enviroments, either script is compiled to the executable like in case of pkg-packaged scripts or there's node binary (e.g. electron or any other web app framework using Node) that calls the script directly, without any need of passing an additional argument for a path to the script. Moreover, I think path could be passed after flags rather than before, which would also cause some inconstancy between the polyfill and native API.

Maybe the code should be prepared for those cases as well?

[ljharb]

Such a compiler should probably be wrapping or building modules such that process.argv has a fictional argument added - otherwise all code that assumes “what node always does” would break.

[SpacingBat3]

@ljharb thank you for the reply, I've actually verified the polyfill behaves exactly the same as Node (not sure why I expected it to work better than this polyfill in terms of the logic) and such compilance is what I think people should care about. That being said, I feel like parseArgs will still change, considering Electron already breaks with the default logic of the args polyfill.

I'll close this issue for now. It might be useful to reopen it after some time, given how many Node.js-based frameworks and tools are there that actually don't care about Node's argv structure.

[shadowspawn]

If your runtime environment follows different conventions than node does with process.argv, then the intended approach is to prepare the arguments yourself and pass them in the configuration:

const result = parseArgs({ args: process.argv.slice(1), strict: false });

The arguments to be parsed were originally a separate parameter, but the normal case is they can be auto-detected so after some discussion they were moved into the configuration.

• Improve API for configuring a high number of arguments #45 (comment)

(For interest, there was explicit support for detecting Electron in the initial submission to the node project, but that got dropped during the pull request to node. Likewise, there was also a suggestion for a process.mainArgs to consult instead of process.argv, still mentioned in the README.)

[SpacingBat3]

If your runtime environment follows different conventions than node does with process.argv, then the intended approach is to prepare the arguments yourself and pass them in the configuration:

const result = parseArgs({ args: process.argv.slice(1), strict: false });

Yeah, that's what I want to do for now. I just thought Node will take care of the argv better, given how default args value were documented:

(…) Default: process.argv with execPath and filename removed.

This is very non-intuitive description of what's done for those who use Node-based frameworks or mess with argv on their own for some reason and expect that this still would work as it should be. It's not a problem on this project's side so I feel OK to leave it as it is.

[shadowspawn]

Oh right, makes it sound smarter than it is! Thanks for clarifying source of confusion.