fix(self-update): respect custom registry when installing pnpm version #10205
Conversation
When managePackageManagerVersions is enabled and a custom registry is configured in .npmrc, pnpm was attempting to auto-install the specified version from registry.npmjs.org instead of respecting the user's custom registry configuration. This happens because installPnpmToTools runs in a temporary directory outside the project, which doesn't automatically pick up the project's .npmrc configuration. The fix explicitly passes the registry configuration from opts.registries.default or opts.rawConfig.registry to the pnpm add command via the --config.registry flag.
|
💖 Thanks for opening this pull request! 💖 |
There was a problem hiding this comment.
Pull Request Overview
This PR fixes an issue where pnpm ignores custom registry configurations when auto-installing a specified pnpm version via managePackageManagerVersions. The fix ensures that when installing pnpm to the tools directory, the custom registry setting is respected by passing it via the --config.registry flag.
- Modified
installPnpmToToolsto check for custom registry configuration and pass it to thepnpm addcommand - Added changeset documenting the fix
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tools/plugin-commands-self-updater/src/installPnpmToTools.ts | Added logic to pass custom registry configuration to the pnpm installation command when available |
| .changeset/cold-buckets-crash.md | Added changeset entry documenting the fix |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
|
Congrats on merging your first pull request! 🎉🎉🎉 |
#10205) * fix(self-update): respect custom registry when installing pnpm version When managePackageManagerVersions is enabled and a custom registry is configured in .npmrc, pnpm was attempting to auto-install the specified version from registry.npmjs.org instead of respecting the user's custom registry configuration. This happens because installPnpmToTools runs in a temporary directory outside the project, which doesn't automatically pick up the project's .npmrc configuration. The fix explicitly passes the registry configuration from opts.registries.default or opts.rawConfig.registry to the pnpm add command via the --config.registry flag. * refactor: self-update * Update .changeset/cold-buckets-crash.md Co-authored-by: Copilot <[email protected]> --------- Co-authored-by: Zoltan Kochan <[email protected]> Co-authored-by: Copilot <[email protected]>
|
This seems to break installs when a custom registry defined in .npmrc has token/credentials too, e.g. private JFrog Artifactory. |
|
Why do you store credentials in the local |
|
should we consider passing the entire project's |
|
when an auth token exists in the .npmrc file, it will not take effect |
I also encountered this problem. It wasn't until the CI/CD process failed that I realized there was this issue. |
|
Thank you all for the feedback regarding the authentication issue with private registries. After reviewing the concerns raised by @msogrin and @Charhua , it appears the current implementation only passes the registry URL but doesn't preserve authentication credentials and other registry-specific configurations from .npmrc. Potential approaches to consider: Fully respect the entire project's .npmrc — Pass the complete .npmrc configuration to the temporary installation directory, preserving all registry settings including authentication tokens and custom configurations. Comprehensively forward registry-related configurations — Extract and pass all registry-related settings (including authentication credentials) from the configuration to the pnpm add command, not just the registry URL. Alternative solutions — Open to suggestions from the community for other viable approaches. I'd appreciate guidance from @zkochan and other maintainers on the preferred direction for addressing this limitation while maintaining security best practices. |
|
For those encountering authentication issues with private registries in the current version, a temporary solution is to downgrade the global base pnpm installation to version <=10.22. Note: This refers to the globally installed pnpm binary, not the version specified in the packageManager field of package.json. Downgrading the global pnpm version reverts to the previous behavior where pnpm is downloaded from registry.npmjs.org, thereby bypassing the authentication token issue entirely. |
|
This seems to break installations that currently do not explicitly use When manage-package-manager-versions=true (the default) pnpm will try to use the global .npmrc instead of the project's .npmrc with Version 10.23 now. |
|
This change has been reverted for now. |
5 participants
Fixes an issue where pnpm ignores custom registry configuration when auto-installing a specified pnpm version via
managePackageManagerVersions.Problem
When
managePackageManagerVersions: trueis set inpnpm-workspace.yamland a custom registry is configured in.npmrc(e.g.,registry=https://registry.npmmirror.com/), pnpm attempts to auto-install the specified version fromregistry.npmjs.orginstead of respecting the user's custom registry configuration.This occurs because
installPnpmToToolsruns in a temporary directory outside the project, which doesn't automatically inherit the project's.npmrcconfiguration.Solution
The fix explicitly passes the registry configuration from
opts.registries.defaultoropts.rawConfig.registryto thepnpm addcommand via the--config.registryflag.Changes
tools/plugin-commands-self-updater/src/installPnpmToTools.tsconst registry = opts.registries?.default || opts.rawConfig?.registrypnpm add command when available:command.push(`--config.registry=${registry}`)Reproduction Steps
Create a
.npmrcfile with a custom registry:Configure
pnpm-workspace.yaml:Set
package.json:{ "packageManager": "[email protected]" }Run
pnpm -vwithout having [email protected] installedBefore fix: pnpm downloads from
registry.npmjs.orginstead of the custom registryAfter fix: pnpm respects the custom registry configuration
Testing
Test setup clarification:
runPnpmCliin the existing test suite?Scope of test coverage:
opts.registries.defaultandopts.rawConfig.registryfallback paths?I'm familiar with testing strategies but would benefit from understanding this project's conventions to ensure consistency with existing test patterns.
Related Issues
Checklist