Conversation
`dist.tarball` in the registry metadata can point at a host other than the registry it was fetched from, typically the registry being mirrored. In that case Corepack downloaded the package manager from that host, bypassing `COREPACK_NPM_REGISTRY` and the credentials configured for it. Resolve the tarball against the registry the metadata came from when it uses the standard `/<package>/-/<file>` layout.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #792
When
COREPACK_NPM_REGISTRYpoints at a registry whose metadata advertisesdist.tarballon a different host, Corepack downloads the package manager from that host instead of the configured registry. Mirrors and proxy repositories do this when they serve tarballs from a CDN or pass the upstreamdistblock through unchanged.installVersiononly rewrites the tarball URL when it starts withhttps://registry.npmjs.org:Any other host falls through untouched. The download then escapes the configured registry, which fails outright when that registry is the only reachable one, and
httpUtils.fetchonly attachesCOREPACK_NPM_TOKENwhen the request origin matchesCOREPACK_NPM_REGISTRY, so a private registry answers 401. The issue reads line 249 as rewriting the URL back to the default registry. The arguments go the other way and that line is harmless; the rewrite is just too narrow.fetchTarballURLAndSignaturenow resolves the tarball against the registry the metadata came from. npm tarball URLs use the/<package>/-/<file>layout, so the package path is taken from the advertised URL and appended to the configured registry, which keeps any path prefix the registry is mounted under (for examplehttps://nexus.example.com/repository/npm-group). A URL that does not use that layout is left alone, so the existing replacement ininstallVersionstill covers it. The trailing-slash normalization fromfetchAsJsonis shared now, so a trailing slash inCOREPACK_NPM_REGISTRYno longer produces a double slash in the tarball URL either.tests/_registryServer.mjscan advertise the tarball on a host other than the registry it serves, viaTEST_TARBALL_HOST. The new test intests/main.test.tsuses it withAUTH_TYPE=COREPACK_NPM_TOKEN. Before the change it fails withUnexpected request to https://cdn.example.org/pnpm/-/pnpm-1.9998.9999.tgzfrom the mock server's request guard; after it passes.NOCK_ENV=replay yarn testis green (172 passed, 1 expected fail) withtests/nocks.dbuntouched, andyarn lintandyarn typecheckpass.