-
Notifications
You must be signed in to change notification settings - Fork 24.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(ngcc): several ngcc fixes and test improvements #44245
Conversation
You can preview 8e4d73c at https://pr44245-8e4d73c.ngbuilds.io/. |
8e4d73c
to
b4e0495
Compare
You can preview b4e0495 at https://pr44245-b4e0495.ngbuilds.io/. |
b4e0495
to
b6a1732
Compare
You can preview b6a1732 at https://pr44245-b6a1732.ngbuilds.io/. |
b6a1732
to
bae78d7
Compare
You can preview bae78d7 at https://pr44245-bae78d7.ngbuilds.io/. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the extensive test updates! 💯
packages/compiler-cli/ngcc/test/dependencies/umd_dependency_host_spec.ts
Outdated
Show resolved
Hide resolved
packages/compiler-cli/ngcc/test/rendering/umd_rendering_formatter_spec.ts
Outdated
Show resolved
Hide resolved
packages/compiler-cli/ngcc/test/rendering/umd_rendering_formatter_spec.ts
Outdated
Show resolved
Hide resolved
…mats (#44245) Previously, ngcc could only handle UMD modules whose wrapper function was implemented as a `ts.ConditionalExpression` (i.e. using a ternary operator). This is the format emitted by popular bundlers, such as Rollup. However, this failed to account for a different format, using `if/else` statements, such as the one [emitted by Webpack][1]. This commit prepares ngcc for supporting different UMD wrapper function formats by decoupling the operation of parsing the wrapper function body to capture the various factory function calls and that of operating on the factory function calls (for example, to read or update their arguments). In a subsequent commit, this will be used to add support for the Webpack format. [1]: https://webpack.js.org/configuration/output/#type-umd PR Close #44245
…#44245) Previously, ngcc could only handle UMD modules whose wrapper function was implemented as a `ts.ConditionalExpression` (i.e. using a ternary operator). This is the format emitted by popular bundlers, such as Rollup. This commit adds support for a different format, that uses `if/else` statements, which is what is [emitted by Webpack][1]. [1]: https://webpack.js.org/configuration/output/#type-umd Fixes #44019 PR Close #44245
…44245) Previously, several ngcc test suites used their own helper to generate test UMD modules. This commit switches to using the same helper for generating UMD modules across test suites. This improves DRYness (ensuring changes/fixes to the UMD format need only be applied once) and makes it easier to test different UMD formats in all test suites. PR Close #44245
This commit utilizes the infrastructure added in the previous commit to run more tests against more of the supported UMD formats. This shall give us more confidence that all aspects of UMD processing work correctly with the various formats. PR Close #44245
… module (#44245) Previously, the ngcc `UmdReflectionHost` would throw a misleading error when trying to collect dependencies of an invalidly formatted UMD module. This happened because an error would be thrown while trying to construct the error message for the actual error, by calling `getText()` on certain TypeScript AST nodes. See #44019 (comment) for a more in-depth explanation. This commit ensures `getText()` can be safely called on TypeScript AST nodes when collecting dependencies of UMD modules. PR Close #44245
…tests (#44245) Previously, the mock packages created for `UmdDependencyHost`'s tests, specified the entry-point as `esm2015`. This does not matter in tests, since the packages are explicitly passed to the `UmdDependencyHost` (while in reality the appropriate host would be determined based on the name of the entry-point property - in this case, detecting the entry-point as ES2015 and not UMD). However, in order to avoid confusion, this commit updates the test packages to use `main` (the default property used for the UMD format in `package.json` files). PR Close #44245
…mats (angular#44245) Previously, ngcc could only handle UMD modules whose wrapper function was implemented as a `ts.ConditionalExpression` (i.e. using a ternary operator). This is the format emitted by popular bundlers, such as Rollup. However, this failed to account for a different format, using `if/else` statements, such as the one [emitted by Webpack][1]. This commit prepares ngcc for supporting different UMD wrapper function formats by decoupling the operation of parsing the wrapper function body to capture the various factory function calls and that of operating on the factory function calls (for example, to read or update their arguments). In a subsequent commit, this will be used to add support for the Webpack format. [1]: https://webpack.js.org/configuration/output/#type-umd PR Close angular#44245
…angular#44245) Previously, ngcc could only handle UMD modules whose wrapper function was implemented as a `ts.ConditionalExpression` (i.e. using a ternary operator). This is the format emitted by popular bundlers, such as Rollup. This commit adds support for a different format, that uses `if/else` statements, which is what is [emitted by Webpack][1]. [1]: https://webpack.js.org/configuration/output/#type-umd Fixes angular#44019 PR Close angular#44245
…ngular#44245) Previously, several ngcc test suites used their own helper to generate test UMD modules. This commit switches to using the same helper for generating UMD modules across test suites. This improves DRYness (ensuring changes/fixes to the UMD format need only be applied once) and makes it easier to test different UMD formats in all test suites. PR Close angular#44245
…r#44245) This commit utilizes the infrastructure added in the previous commit to run more tests against more of the supported UMD formats. This shall give us more confidence that all aspects of UMD processing work correctly with the various formats. PR Close angular#44245
… module (angular#44245) Previously, the ngcc `UmdReflectionHost` would throw a misleading error when trying to collect dependencies of an invalidly formatted UMD module. This happened because an error would be thrown while trying to construct the error message for the actual error, by calling `getText()` on certain TypeScript AST nodes. See angular#44019 (comment) for a more in-depth explanation. This commit ensures `getText()` can be safely called on TypeScript AST nodes when collecting dependencies of UMD modules. PR Close angular#44245
…tests (angular#44245) Previously, the mock packages created for `UmdDependencyHost`'s tests, specified the entry-point as `esm2015`. This does not matter in tests, since the packages are explicitly passed to the `UmdDependencyHost` (while in reality the appropriate host would be determined based on the name of the entry-point property - in this case, detecting the entry-point as ES2015 and not UMD). However, in order to avoid confusion, this commit updates the test packages to use `main` (the default property used for the UMD format in `package.json` files). PR Close angular#44245
Previously, when processing UMD, ngcc assumed that the `exports` argument of the CommonJS factory call (if present) would be the first argument of the call. This is generally true for the supported UMD formats, but can change if ngcc prepends more imports (and thus factory arguments) while processing the module. This could lead to errors when trying to collect dependencies of an already processed module. (This was accidentally broken in angular#44245 (commit 2bc3522).) This commit fixes it by not making any assumptions about the position of an `exports` argument in the CommonJS factory call. Fixes angular#44380
Previously, when processing UMD, ngcc assumed that the `exports` argument of the CommonJS factory call (if present) would be the first argument of the call. This is generally true for the supported UMD formats, but can change if ngcc prepends more imports (and thus factory arguments) while processing the module. This could lead to errors when trying to collect dependencies of an already processed module. (This was accidentally broken in angular#44245 (commit 2bc3522).) This commit fixes it by not making any assumptions about the position of an `exports` argument in the CommonJS factory call. Fixes angular#44380
Previously, when processing UMD, ngcc assumed that the `exports` argument of the CommonJS factory call (if present) would be the first argument of the call. This is generally true for the supported UMD formats, but can change if ngcc prepends more imports (and thus factory arguments) while processing the module. This could lead to errors when trying to collect dependencies of an already processed module. (This was accidentally broken in #44245 (commit 2bc3522).) This commit fixes it by not making any assumptions about the position of an `exports` argument in the CommonJS factory call. Fixes #44380 PR Close #44381
Previously, when processing UMD, ngcc assumed that the `exports` argument of the CommonJS factory call (if present) would be the first argument of the call. This is generally true for the supported UMD formats, but can change if ngcc prepends more imports (and thus factory arguments) while processing the module. This could lead to errors when trying to collect dependencies of an already processed module. (This was accidentally broken in #44245 (commit 2bc3522).) This commit fixes it by not making any assumptions about the position of an `exports` argument in the CommonJS factory call. Fixes #44380 PR Close #44381
Previously, when processing UMD, ngcc assumed that the `exports` argument of the CommonJS factory call (if present) would be the first argument of the call. This is generally true for the supported UMD formats, but can change if ngcc prepends more imports (and thus factory arguments) while processing the module. This could lead to errors when trying to collect dependencies of an already processed module. (This was accidentally broken in #44245 (commit 2bc3522).) This commit fixes it by not making any assumptions about the position of an `exports` argument in the CommonJS factory call. Fixes #44380 PR Close #44382
…mats (angular#44245) Previously, ngcc could only handle UMD modules whose wrapper function was implemented as a `ts.ConditionalExpression` (i.e. using a ternary operator). This is the format emitted by popular bundlers, such as Rollup. However, this failed to account for a different format, using `if/else` statements, such as the one [emitted by Webpack][1]. This commit prepares ngcc for supporting different UMD wrapper function formats by decoupling the operation of parsing the wrapper function body to capture the various factory function calls and that of operating on the factory function calls (for example, to read or update their arguments). In a subsequent commit, this will be used to add support for the Webpack format. [1]: https://webpack.js.org/configuration/output/#type-umd PR Close angular#44245
…angular#44245) Previously, ngcc could only handle UMD modules whose wrapper function was implemented as a `ts.ConditionalExpression` (i.e. using a ternary operator). This is the format emitted by popular bundlers, such as Rollup. This commit adds support for a different format, that uses `if/else` statements, which is what is [emitted by Webpack][1]. [1]: https://webpack.js.org/configuration/output/#type-umd Fixes angular#44019 PR Close angular#44245
…ngular#44245) Previously, several ngcc test suites used their own helper to generate test UMD modules. This commit switches to using the same helper for generating UMD modules across test suites. This improves DRYness (ensuring changes/fixes to the UMD format need only be applied once) and makes it easier to test different UMD formats in all test suites. PR Close angular#44245
…r#44245) This commit utilizes the infrastructure added in the previous commit to run more tests against more of the supported UMD formats. This shall give us more confidence that all aspects of UMD processing work correctly with the various formats. PR Close angular#44245
… module (angular#44245) Previously, the ngcc `UmdReflectionHost` would throw a misleading error when trying to collect dependencies of an invalidly formatted UMD module. This happened because an error would be thrown while trying to construct the error message for the actual error, by calling `getText()` on certain TypeScript AST nodes. See angular#44019 (comment) for a more in-depth explanation. This commit ensures `getText()` can be safely called on TypeScript AST nodes when collecting dependencies of UMD modules. PR Close angular#44245
…tests (angular#44245) Previously, the mock packages created for `UmdDependencyHost`'s tests, specified the entry-point as `esm2015`. This does not matter in tests, since the packages are explicitly passed to the `UmdDependencyHost` (while in reality the appropriate host would be determined based on the name of the entry-point property - in this case, detecting the entry-point as ES2015 and not UMD). However, in order to avoid confusion, this commit updates the test packages to use `main` (the default property used for the UMD format in `package.json` files). PR Close angular#44245
Previously, when processing UMD, ngcc assumed that the `exports` argument of the CommonJS factory call (if present) would be the first argument of the call. This is generally true for the supported UMD formats, but can change if ngcc prepends more imports (and thus factory arguments) while processing the module. This could lead to errors when trying to collect dependencies of an already processed module. (This was accidentally broken in angular#44245 (commit 2bc3522).) This commit fixes it by not making any assumptions about the position of an `exports` argument in the CommonJS factory call. Fixes angular#44380 PR Close angular#44381
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. |
See individual commits for details.
Fixes #44019.