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] v7.3.0 publish --dry-run will require login, and publishConfig from package.json load after the check (ENEEDAUTH) #2411

Closed
dr-js opened this issue Dec 24, 2020 · 6 comments · Fixed by #2422 or #2445
Labels
Bug thing that needs fixing Release 7.x work is associated with a specific npm 7 release

Comments

@dr-js
Copy link
Contributor

dr-js commented Dec 24, 2020

Current Behavior:

publish --dry-run with v7.3.0 will require login (ENEEDAUTH)

Expected Behavior:

publish --dry-run should work when not login, like in CI env.

Steps To Reproduce:

mkdir ./test-publish-dry-run/
cd ./test-publish-dry-run/
npm init --yes
npx --yes npm@6 publish --dry-run # will pass
npx --yes npm@7.3.0 publish --dry-run # will error

Sample error log:

# npm publish --dry-run
npm ERR! code ENEEDAUTH
npm ERR! need auth This command requires you to be logged in.
npm ERR! need auth You need to authorize this machine using `npm adduser`

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-12-24T16_00_58_505Z-debug.log

Environment:

  • OS: Ubuntu 18.04
  • Node: 14.15.3
  • npm: 7.3.0
@dr-js dr-js 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 Dec 24, 2020
@foxxyz
Copy link
Contributor

foxxyz commented Dec 24, 2020

Can confirm this is happening on my end also.

Additionally, publishConfig settings in package.json no longer seem to be respected. I have a publishConfig with a custom registry set and npm publish seems to be checking my public npm registry auth and failing instead of looking at my private registry.

npm publish --registry myregistry works as a workaround.

Environment

  • OS: MacOS Big Sur
  • Node: 15.5.0
  • npm: 7.3.0

@foxxyz
Copy link
Contributor

foxxyz commented Dec 24, 2020

Upon further inspection, this seems related to #2360 and changes in be4a090.

In lib/publish.js, the new registry auth check seems to be being done too early in publish() , as the checks for dry-run and publishConfig option merges don't occur until _publish().

@justinGML
Copy link

justinGML commented Dec 28, 2020

Thanks @foxxyz, that workaround worked for me too. I experienced this issue when attempting to deploy to a GitLab private repo. I would imagine this would break the build pipeline for anyone else following the example configuration in the GitLab docs: https://docs.gitlab.com/ee/user/packages/npm_registry/#publish-an-npm-package-by-using-cicd

@dr-js dr-js changed the title [BUG] v7.3.0 publish --dry-run will require login (ENEEDAUTH) [BUG] v7.3.0 publish --dry-run will require login, and publishConfig from package.json load after the check (ENEEDAUTH) Dec 29, 2020
@thw0rted
Copy link

I don't want to sidetrack this issue too much but if dry-run doesn't try to log in at all, what should I use to test that my stored credential works (without actually publishing a package)?

@dr-js
Copy link
Contributor Author

dr-js commented Dec 29, 2020

@thw0rted try npm whoami?

@thw0rted
Copy link

Nice! Thanks, I just learned about the command today but didn't realize it was actually making a network request. Adding a --verbose flag shows the request URL and response status.

One caveat is that whoami works against the resolved registry value without touching publishConfig, I guess because you might need auth for the "get" registry (i.e. for npm install). I was thinking it'd be nice if whoami had a flag to run in "publish mode", something like npm whoami --publish, which would avoid having to dig around in your package file to find the URL to pass to --registry.

dr-js added a commit to dr-js/dr-dev that referenced this issue Jan 5, 2021
notable change:
- deprecate: `fileProcessorWebpack`
- add: `copyAfterEdit` to `node/file`
- temp-fix: ci: wait for npm/cli#2411
- script sort
- package update
dr-js added a commit to dr-js/dr-dev that referenced this issue Jan 5, 2021
notable change:
- deprecate: `fileProcessorWebpack`
- add: `copyAfterEdit` to `node/file`
- temp-fix: ci: wait for npm/cli#2411
- script sort
- package update
dr-js added a commit to dr-js/dr-dev that referenced this issue Jan 5, 2021
notable change:
- deprecate: `fileProcessorWebpack`
- temp-fix: ci: wait for npm/cli#2411
- temp-fix: ci: cache: wait for: actions/runner-images#2153
- fix: use `@dr-js/core@0.4.3-dev.1` with fix for nodejs@15.5 caused responder send noop
- fix: output: log git diff in git status check
- fix: test: treat `before|after` the same as `it`
- add: `copyAfterEdit` to `node/file`
- add: bin: `is-hash-changed` to `cache-step`
- add: ci: `.github/ci-patch.js` for doing ci patch in one place
- node: use `getToggle` for `Preset.Toggle`
- bin: suppot `checksum-file-only` for `cache-step`
- bin: sort babel resolve path & test
- bin: sort `cache-step` options
- ci & script sort
- package update
@wraithgar wraithgar removed the Needs Triage needs review for next steps label Jan 6, 2021
@dr-js dr-js closed this as completed Jan 30, 2021
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
6 participants
@wraithgar @thw0rted @foxxyz @dr-js @justinGML and others