Conversation
A library compiles with importHelpers, so a bundle can carry a live 'import ... from tslib' while the library's own manifest declares nothing and the built package gets no dependencies field at all. On a hoisted node_modules it resolves anyway; on a strict layout the consumer gets ERR_MODULE_NOT_FOUND at runtime. The range comes from @angular/compiler, resolved from the workspace, which is what ng-packagr reads. A tslib the library already declares, in either dependencies or peerDependencies, is left alone. Fixes angular#34131
![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 automatically adds the tslib dependency to a library's generated package.json if it is not already declared, resolving the version range from @angular/compiler in the workspace. The feedback recommends extending this check to also ignore tslib if it is already defined in optionalDependencies, and adding a corresponding unit test to verify this behavior.
|
Since most libraries won't need |
| * which is what ng-packagr reads too. A missing or unreadable manifest is not an error: the | ||
| * output then keeps exactly the dependencies the library declared itself. | ||
| */ | ||
| function resolveAngularTslibRange(workspaceRoot: string): string | undefined { |
There was a problem hiding this comment.
Since tslib is both backward and forward compatible, using the latest version of the library should be sufficient here.
There's also no guarantee that tslib will even be present in @angular/compiler or that it is resolvable from the workspace root.
2 participants
PR Checklist
PR Type
What is the current behavior?
Issue Number: #34131
Library builds force
importHelpers, and bare specifiers are externalized, so an emitted bundle can carry a liveimport ... from 'tslib'.generatePackageManifestsonly passesdependenciesthrough from the source manifest and never creates it, so a library that does not declare tslib itself produces a package with nodependenciesfield at all. On ng-zorro-antd 34 of 105 bundles import tslib. With a hoisted node_modules it resolves anyway; on a strict layout the consumer getsERR_MODULE_NOT_FOUND ... 'tslib'.What is the new behavior?
The built package declares tslib when the library does not, taking the range from
@angular/compilerresolved against the workspace. That is the same source ng-packagr reads, so the two builders agree.A tslib the library already declares, in
dependenciesor inpeerDependencies, is left exactly as it is. When@angular/compilercannot be resolved nothing is added and the output keeps the dependencies the library declared.The range is resolved in
normalizeOptions, where the builder already reads the filesystem, sogeneratePackageManifestsstays pure and the four new cases are plain unit tests.Does this PR introduce a breaking change?
Other information
ng-packagr also moves a
peerDependencies.tslibintodependencieswith a warning. That is not done here: it is a separate behaviour change and this function has no logger.I could not run the builder tests locally, so CI is the first run of them.