Skip to content
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

Closed
MarshallOfSound opened this issue Nov 23, 2020 · 3 comments
Assignees
Labels
Bug thing that needs fixing Release 7.x work is associated with a specific npm 7 release

Comments

@MarshallOfSound
Copy link

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 makenpx` 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@7

Environment:

  • OS: macOS 11.0
  • Node: 15.2.1
  • npm: 7.0.12
@MarshallOfSound MarshallOfSound added Bug thing that needs fixing Needs Triage needs review for next steps Release 7.x work is associated with a specific npm 7 release labels Nov 23, 2020
@nlf
Copy link
Contributor

nlf commented Nov 23, 2020

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 npx there are some workarounds that may do the trick for you:

npm_config_yes=true npx thing passes the --yes via environment variable and works correctly in both npm 6 and 7.

additionally, if your npx command is being run in an environment where you do not have a stdin available the prompt is bypassed and the old behavior kicks in, which means npx thing </dev/null, which forcibly closes stdin, is also effective.

@nlf nlf self-assigned this Nov 23, 2020
@nlf nlf removed the Needs Triage needs review for next steps label Nov 23, 2020
@MarshallOfSound
Copy link
Author

MarshallOfSound commented Nov 24, 2020

npm_config_yes=true appears to do the job for us, would be good to document that somewhere as I'm sure other folks will be having similar issues as folks update to npm@7. Or making it slightly more obvious what that config option does, I assume looking at npm's option parser that npm_config_yes will make any check for .yes be truthy regardless of intention. Perhaps a slightly safer npm_config_no_npx_prompt kinda thing would be more specific?

Refs: electron/electron#26662

@nlf
Copy link
Contributor

nlf commented Nov 24, 2020

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 --yes flag is npm init

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Release 7.x work is associated with a specific npm 7 release
Projects
None yet
Development

No branches or pull requests

2 participants