The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
invalid command line flags are ignored vs throwing error / usage
If an invalid command line flag / switch is provided, npm will continue, rather than throwing an error and giving the help text for that context.
% npm audit --format=asdfasfd --123 asdf
will simply act as if you had typed
% npm audit
vs returning usage and exiting non-0.
More generally, standardizing processing of both positional arguments and command line flags might be a big plus in terms of keeping the tool consistent and well documented.
It was suggested in https://github.com/npm/npm/issues/20856 that I bring it up here; also submitted:
I really wish we could do this. We may be able to for commands like
npm audit (but not
npm audit fix), but doing so for
npm install and it’s related family of commands, is vastly more difficult:
npm passes all of its config options and command line arguments together through to scripts that it runs in the environment. This includes unknown arguments. There are a number of build tools that take advantage of this so that you can just add their config to your
.npmrc or pass it in as extra arguments to
npm i and they get it automatically.
Erroring on invalid options would break these use cases.
npm run? I think you normally have to pass command line flags w/
-- if you want to pass them to a subcommand?
For example, I typically have to do
npm run xyz -- -y if I want to pass in the
-y argument to the command that
xyz is running.
I think that’s the usual convention for passing flags to a command run by another command, right?
npm run is probably not a bad starter case either.
Just want to add that ignoring unknown flags is a security issue (or at least, it is a UX issue that can give users a false sense of security and can lead to unexpected behavior). For example, before setting up an alias for
npm i --ignore-scripts, I would often mistakenly run
npm i --no-scripts ... without realizing scripts were being executed.
This problem was discussed in https://github.com/npm/npm/issues/14396 and a few other github issues but it was treated more like a quality of life issue. This really downplays the footgun potential of the current behavior