-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] New --yes behavior in npx is a breaking change that can't easily be handled #2226
Comments
hi! the confirmation prompt was added as a safety measure to help prevent users from accidentally running code that they did not intend to run. while we won't be removing the prompt while using
additionally, if your |
Refs: electron/electron#26662 |
i agree a safer alias wouldn't be a bad idea. for what it's worth, as of now the only other command that cares about the as for docs, we do describe how environment variables are mapped to configuration here: https://docs.npmjs.com/cli/v7/using-npm/config#environment-variables |
Current Behavior: (npx@7)
npx thing
prompts the user that "thing" will be installed and forces them to type "yes"You can bypass this by providing
npx --yes thing
.Expected Behavior:
npx thing
installs and runs "thing" or a backwards compatible option is provided to bypass the prompt.The fundamental issue here is that npx --yes thing
**is not compatible** with npx@6, this means that any kind of generic CI scripts / build scripts need to somehow detect the version of npx being used and conditionally provide
--yesor not. This is going to make
npx` style commands significantly less portable in CI / build environments because they'll either not work for all environments or all have to come with this "if npx --version === 7" wrapper.Would be great to reconsider this new
--yes
behavior.Steps To Reproduce:
npx <thing>
on npm@7Environment:
The text was updated successfully, but these errors were encountered: