[RC-only version] build: ship partial compilation output with APF v13 #23710
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Updates to the latest version of Angular v13, and updates the Bazel setup in preparation for wiring up the APF v13 changes
…pe definitions Since we updated the TypeScript module and target to ES2020/ESNext for both devmode and prodmode output, tbe type definition files will no longer get the AMD naming patches from `@bazel/typescript`. These previously ensured that with `module: "umd"`, TypeScript never can generate relatie imports, but rather uses AMD module names. The removal of this logic now breaks the type definition output because there is code in `@angular/material-experimental` which imports from Angular Material core in a way where TypeScript would try to write an inferred type into the `d.ts` out. This results in a deep import right now because some of the symbols used for the inferred type are not publicly exposed. This commit exposes them privately so that TS can avoid deep imports. The goldens have been updated accordingly. The deep imports can be observed there as well.
As of APF v13, we no longer ship UMD files. This means that we can remove all the logic for keeping track of the UMD global names. Instead we just keep track of external packages which should not be bundled into the package output (this includes cross-entry point imports; e.g. slider should not bundle the core entry-point; so we still need to keep track of all the entry-points as externals)
As of APF v13, Angular packages come with partial compilation output. This means that for tests, or running the dev-app we want to run the linker to avoid JIT compilation of the FW code. This commit introduces a macro for generating linked ESM bundles of framework packages and their entry-points. These bundles can then be passed later to tests or the dev-app, so that it would not need to run the linker at all. This helps speeding up the development turnaround as the linker would not need to re-run *always*..
Removes all View Engine workarounds that we previously needed to generate the APF package output with View Engine.
Switches the devmode output to ES2020 and ESM. This is in preparation for allowing fast rebuilds with the Angular FW v13 packages. Since these packages are now strict ESM, and rely on the linker, we need to have some bundling in between for tests, or the dev-app (this is actually even faster than relying on ConcatJS/RequireJS/SystemJS). This bundling should not need to consume the prodmode output, but rather use the devmode output because otherwise the usual development workflow would result in both devmode + prodmode being requested.. resulting in a significant slow-down due to 2x TS compilations. Devmode output is always requested for dependencies on `ts_library` or `ng_module` to accomplish the TS fine-grained TS compilations. Since this is the case, we just naturally use the devmode output for bundling of tests/dev-app.. so inherently we need to switch devmode to ESM for enabling bundling.
For APF v13, we have removed the `entry_point` attribute from the `ng_package` rule. This attribute did not do what it described. i.e. it was not responsible for determining the primary package entry-point. This commit removes all of these usages as they are no longer valid, nor needed.
For APF v13, we will switch to the custom devserver we have used for the dev-app as well. We do this because the ConcatJS devserver is no longer needed due to us bundling the e2e-app. Note again: This is needed because FW packages do no longer ship UMD files, and we also need to consolidate our pre-built linker ESM bundles of the Angular framework packages. A bundler like ESBuild will do that job for us. It's fast enough that it's subjectively significantly faster than ConcatJS/RequireJS resolving deps at runtime in the browser..
…ser tests Replaces the legacy gulp setup with a simple script that runs the Angular compiler and ESBuild with the linker. This is simpler than switching the Gulp legacy output to properly deal with the FW packages using partial compilation output together with SystemJS. It has been a long goal removing SystemJS and the gulp tooling anyway, so this is a good chance for simplifying this code.. removing the need for all these additional tsconfig files; and additional configuration of the legacy gulp tooling when wiring up new packages.
Updates the linker integration test to no logner use deep imports into the stict ESM package of `@angular/compiler-cli`. The linker integration test tooling is now using ESM as well; in order to be able to import into the compiler-cli.
Updates the build setup to no longer support the View Engine mode through a Bazel define flag.
Previously, the dev-app relied on SystemJS for resolving all files. This required a lot of configuration and was very cumbersome to maintain. This commit switches both serve-targets to use ESBuild instead. ESbuild will resolve all the dependencies for us at build time; removing the manual configuration work, and it will also allow us to incorporate the linked framework ESM bundles, so that the apps would not need the Angular compiler at runtime (for JIT). Generally it seems that ESBuild is extremely fast so that it makes up for the runtime resolution through SystemJS; and manual configuration work. It also makes our tooling more modern and easier to adopt to new changes (e.g. if we'd add a dependency like `date-fns` there is no special tooling needed).
Similar to the reason why we switched the dev-app and e2e-app to use ESBuild, we will use ESBuild as a step in between for running browser Karma tests, or running e2e protractor/selenium-webdriver tests. This allows us to incorporate the framework linked ESM bundles and helps working around the change that no UMD bundles are available for APF v13 packages. Running ESBuild as a build step in between seems non-significant as on the other hand the module resolution in the browser for Karma seemed noticeable slower (due to it loading hundreds of files individually); and also the Karma browser setup required more manual maintenance (through RequireJS configurations).
This commit updates the pre-render test to work with APF v13 package output which is strict ESM. Since the test runs inside Node, we would need to update our test to run in ESM as well. This is not possible with the Bazel NodeJS rules yet, and also there are a couple of more issues with running ESM devmode directly in NodeJS: * ESM requires an explicit extension for releative imports. TypeScript will not add an explict extension so this breaks for our local package output. A bundler is needed and this is what the CLI will do for SSR as well. * We want the Angular linked ESM bundles for framework packages as these are only partially compiled. This is not possible to do without modifiyng the node modules / or using a bundler that in-memory modifies the resolved framework packages (like the CLI does with its webpack plugins).
There were a couple of code places which started breaking with us switching the devmode/prodmode target and mode to ES2020: * Since devmode is now ES2020, arrow functions are no longer downleveled for tests to actual `function` declarations. This breaks spies in google-maps or the youtube-player package as the tests try to instantiate a spy using `new`. An arrow function cannot be instantiated through `new`.. so we manually update these spies to not use arrow functions. * The MDC-based dialog harness extended from the non-MDC dialog harness and the `with` static member conflicted. It's unclear why this in particular happened but it was straightforward enough to just introduce a base class for the dialog harness (like it is done in other places as well).
Removes all the ngcc compatibility CI jobs as the APF v13 output no longer comes with View Engine output and makes ngcc a noop for the Angular Component package output.
Removes the unused `linker-process` Bazel rule. We no longer need this AMD-based Bazel transformation/middleman rule as we can directly run the linker when bundling unit tests.
The CLI does not yet support running schematics as ESM. For this we actually still emit CommonJS output for schematics. We need to add a sub-directory `package.json` for the schematic folders though as otherwise NodeJS would incorrectly treat the `.js` schematic files as ESM due to the top-level package.json file setting `type: module`.
Adds a subpath export for the `fesm2020` folder of the internal `@angular/components-examples` package. This subpath is needed so that Webpack can generate lazy-loadable chunks for all examples in the documentation app.
Adds the `exports` field for module resolution of `@angular/cdk` and `@angular/material` when Sass is requested. Since these packages use the `exports` field already, to prevent deep imports, we also need to expose the Sass entry-points and prebuilt files. The webpack loader requires the `sass` conditional to be set when the CDK or Material modules are loaded without the `includePaths` option. It is worth noting that the Sass webpack loader does not seem to respect the exports field when `@import` is used. Still for consistency and other potential bundlers/loaders, we will expose the `.css` extension subpaths. Also as a side-note: the `.css` extension imports do not work with `@use`, so the non-extension variants are helpful there for backwards compatibility & convenient access.
Updates the Node version used in Bazel so that it does not fail with the minimium node version from Angular FW packages.
josephperrott
added
P1
josephperrott
requested review from
andrewseguin,
crisbeto,
devversion,
jelbourn and
mmalerba
as code owners
google-cla
bot
added
cla: no
josephperrott
added
cla: yes
This comment has been minimized.
This comment has been minimized.
google-cla
bot
added
cla: no
This comment has been minimized.
This comment has been minimized.
google-cla
bot
added
cla: no
This comment has been minimized.
This comment has been minimized.
josephperrott
added
cla: yes
This comment has been minimized.
This comment has been minimized.
google-cla
bot
added
cla: no
This comment has been minimized.
This comment has been minimized.
2 similar comments
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
josephperrott
added
cla: yes
devversion
approved these changes
Oct 8, 2021
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
RC specific cherry-picked version of #23689