fix(@angular/cli): handle npm-aliased and unfetchable packages in ng update#32943
fix(@angular/cli): handle npm-aliased and unfetchable packages in ng update#32943maruthang wants to merge 1 commit into
Conversation
…update When `ng update` encounters packages using npm aliases (`npm:` protocol) or packages that cannot be fetched from the registry (private registries, JSR, AWS CodeArtifact), the entire update process would fail with a 404 error because `Promise.all()` rejects on any single fetch failure. The fix: 1. Filters out `npm:` aliased packages early in `isPkgFromRegistry()` since the dependency key name differs from the actual package name 2. Catches individual fetch errors in the parallel metadata fetch, returning a partial result that the existing reduce logic already handles gracefully Closes angular#28834
![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 enhances the Angular CLI update schematic to better handle npm aliases and metadata fetch failures by returning partial results on error. The review feedback recommends a more robust implementation for alias detection using the npa.resolve result type rather than a simple string prefix check.
| // npm: aliases (e.g., "npm:real-package@^1.0.0") resolve as registry packages | ||
| // but the dependency key name differs from the actual package name, so registry | ||
| // lookups using the alias name would fail with a 404. | ||
| if (specifier.startsWith('npm:')) { | ||
| return false; | ||
| } | ||
|
|
||
| const result = npa.resolve(name, specifier); | ||
|
|
||
| return !!result.registry; |
There was a problem hiding this comment.
Using the result of npa.resolve to detect aliases is more robust than a manual string prefix check. This approach handles edge cases like case-insensitivity (e.g., NPM:) and potential whitespace consistently with how the rest of the package resolution logic operates.
| // npm: aliases (e.g., "npm:real-package@^1.0.0") resolve as registry packages | |
| // but the dependency key name differs from the actual package name, so registry | |
| // lookups using the alias name would fail with a 404. | |
| if (specifier.startsWith('npm:')) { | |
| return false; | |
| } | |
| const result = npa.resolve(name, specifier); | |
| return !!result.registry; | |
| // npm: aliases (e.g., "npm:real-package@^1.0.0") resolve as registry packages | |
| // but the dependency key name differs from the actual package name, so registry | |
| // lookups using the alias name would fail with a 404. | |
| const result = npa.resolve(name, specifier); | |
| return !!result.registry && result.type !== 'alias'; |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
2 participants
Summary
ng updatewould fail with a 404 error whenpackage.jsoncontains dependencies using npm aliases ("my-pkg": "npm:real-package@^1.0.0") or packages from private/non-npmjs registriesPromise.all()for fetching package metadata would reject entirely when any single package couldn't be fetched, even if it wasn't part of the updatenpm:aliased packages early (since the alias name differs from the real package name) and catches individual fetch errors gracefully, allowing the existing reduce logic to handle missing packagesCloses #28834
Test plan
ng updateon a project withnpm:aliased dependencies — should complete without errorng updateon a project with private registry packages — should skip unfetchable packages gracefullyng update @angular/coreon a normal project — should work as before