fix(@angular/cli): copy project config files to temp directory during ng update#32959
fix(@angular/cli): copy project config files to temp directory during ng update#32959ptu14 wants to merge 1 commit into
Conversation
Sorry, something went wrong.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a copyConfigFromProject flag to the package manager descriptors to ensure that project-specific configuration files are correctly copied into temporary directories during package acquisition. This change improves support for private registries and custom configurations. I have identified two potential issues: first, the flag is missing from the modern Yarn descriptor, which may lead to inconsistencies; second, including pnpm-workspace.yaml in the configFiles list for pnpm might trigger unintended workspace-related behavior in the isolated temporary environment.
Sorry, something went wrong.
ptu14
force-pushed
the
fix/ng-update-copy-project-npmrc
branch
from
6aa2cd4 to
7613be7
Compare
April 8, 2026 14:19
alan-agius4
added
action: review
The PR is still awaiting reviews from at least one requested reviewer
target: patch
This PR is targeted for the next patch release
labels
Apr 8, 2026
Reviewers
1 more reviewer
2 participants
Fixes #27163
PR Checklist
Please check to confirm your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
During
ng update, the CLI installs a temporary version of itself in a system temp directory (e.g./tmp/angular-cli-packages-xxx). Since this directory is outside the project tree, npm/pnpm/yarn-classic cannot find the project's.npmrcand falls back to the user-level~/.npmrc. This causes registry settings defined in the project's.npmrcto be ignored.Issue Number: #27163
What is the new behavior?
Project configuration files (
.npmrc,.yarnrc,pnpm-workspace.yaml) are now copied to the temporary directory before runningnpm install. This reuses the existingcopyConfigFromProjectmechanism (previously only enabled for bun) for npm, pnpm, and yarn-classic.Does this PR introduce a breaking change?