-
Notifications
You must be signed in to change notification settings - Fork 333
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
v17 request error when checking packages in a private registry #1436
Comments
Thanks for reporting. Can you tell me the last v17 prerelease that works for you? i.e. v17.0.0-1..v17.0.0-7 There must be some npm auth config that is not being set properly. It likely occurred in the conversion from |
17.0.0-3 ~/Git/Acme/my-project $ npm i -g npm-check-updates@17.0.0-3
added 101 packages, and changed 1 package in 9s
14 packages are looking for funding
run `npm fund` for details
~/Git/Acme/my-project $ ncu
Checking /Users/jdoe/Git/Acme/my-project/package.json
[====================] 46/46 100%
typescript-eslint ^7.18.0 → ^8.0.0
Run ncu -u to upgrade package.json
~/Git/Acme/my-project $ npm i -g npm-check-updates@17.0.0-4
removed 101 packages, and changed 1 package in 4s
~/Git/Acme/my-project $ ncu The last command results in the same error as above. |
That is definitely caused by switching from https://github.com/npm/pacote to https://github.com/npm/npm-registry-fetch (#1329). I will need to set up a scoped package in a private registry and try to get the auth config similar to reproduce. If someone can reproduce this and wants to take a stab at it that would be a big help. |
Scoped package names were not URL encoded as they should be meaning the scope was treated as the package name and the package name was treated as the version by some registry implementations. The usage of `node:path` rather than a proper URL API resulted in the stripping of one of the slashes after http(s):// Comparing the behaviour of npm-check-update v16 vs v17 before this patch v16 generated URLs like https://registry/@scope%2fname v17 generated URLs like https:/registry/@scope/name fixes raineorshine#1436
Hi, I believe the core issue here was the fact that package names weren't properly URL encoded, the authentication may have actually been successful given that the registry responded with a 400 rather than a 403 and an error that the package name was just the scope. But just to be sure I fixed both the URL formatting issue and the URL encoding of the package names in PR #1438 which works fine in my local testing |
Scoped package names were not URL encoded as they should be meaning the scope was treated as the package name and the package name was treated as the version by some registry implementations. The usage of `node:path` rather than a proper URL API resulted in the stripping of one of the slashes after http(s):// Comparing the behaviour of npm-check-update v16 vs v17 before this patch v16 generated URLs like https://registry/@scope%2fname v17 generated URLs like https:/registry/@scope/name fixes raineorshine#1436
Published in |
I'm still getting this issue in 17.1.1, downgrading to version 16.14.20 works.
|
@LeahPike that does actually look like something different, it seems the request is sent to the correct repo and the registry correctly identifies the package according to the response |
Steps to Reproduce
Scoped package in a private registry (authenticated) defined in dependencies. Successful check with v16, failure with v17.
Steps:
npm i -g npm-check-updates@17.0.0
ncu
npm i -g npm-check-updates@16.14.0
ncu
Current Behavior
Expected Behavior
Succesful check as in v16.
The text was updated successfully, but these errors were encountered: