Updates the size goldens for the integration CLI tests to
reflect the new payload with APF v13 and the CLI v13-next.7
Overall, there seems to be some increase in the polyfills
and a ~400b increase for the `main` bundles. This seems to
because with APF v13, the core package no longer uses the
downleveled `Object.assign`, but the spread operator directly.
ESbuild will then downlevel the spread to `__spreadProps` which
seems to come with more transitively-required helpers that
end up contributing to the ~400b increase. The spread is downleveled
even for the modern browsers this integration test targets, because
it is a trick to wrokaround a performance bug in V8. So the size
increase is reasonable given the runtime improvement. More details
here:
https://github.com/evanw/esbuild/issues/951#issuecomment-796972298.
PR Close#43431
Updates the size goldens for the two AIO production build jobs.
Due to the removal of differential loading, the bundle names no
longer include the ES version being used, so we remove that suffix.
The styles overall decreased. Additionally, the main bundle became
noticable smaller, with a little increase in the polyfills. The AIO
job not using APF v13 seems larger but this is likely due to the current
Angular v13 packages (in the `test_aio`) job still using View Engine
APF v12 with the CLI v13 (where some optimizations might not match up anymore).
PR Close#43431
This commits sets the JS target for all command line tools to
NodeJS v12. ESbuild will automatically downlevel the ES2020 features
we currently use to make them compatible with NodeJS v12 <-> ES2019.
ES2020 is the prodmode output, but we still support Node v12 so
there needs to be some downleveling for now.
Note: This is a separate commit because initially the target was
set to Node v14 to match up with the prodmode Bazel output.
PR Close#43431
Simplifies the `last_segment_name` computation in the integration
test Starlark macro we use. The last segment name could be computed
in a shorter way and this has come up while being at it (through review;
so this commit addresses that).
PR Close#43431
Similar to the other private entry-points we have added for localize,
bazel or the migrations, we should expose the tooling code through
a dedicated private export. This will make the compiler-cli exports
more consistent and it will become easier for the CLI to export
necessary code.
PR Close#43431
Currently, some tests in the `compiler-cli/integrationtest` package fail
on Windows because there are spec files which are not Bazel-generated.
When Bazel runs these tests on Windows, the spec file is resolved to
the actual source file (since there is no runfile symlinking/sandboxing).
This breaks the execution of the CJS spec file since it resides in th
`packages/compiler-cli` source folder which has a `package.json` set to
`type: module`.
We fix this by adding a `package.json` file for the integration test
folder and setting `module` to `commonjs`.
PR Close#43431
The package builder script should respect the `BAZEL` environment
variable for running Bazel. If not set, it can fallback to bazelisk
from the `node_modules`. Respecting this variable allows for users
with a global `bazel` binary. This is desirable in some situations,
like on Windows, where running Bazel inside of the Yarn environment
seems slower than running a global variant. This could appear like that
because projects might use different Bazel versions. In some cases,
developers would want to use a single (already-warmed-up) instance of
Bazel instead of launching different versions using bazelisk.
(e.g. when switching a lot between repos like COMP, FW or CLI..)
In any case, it doesn't hurt providing this flexibility for advanced
use-cases. It's low-effort to maintain and is respected in COMP as well.
PR Close#43431
Temporarily disables the Bazel integration test as it will not
work with the APF v13 output which is strict ESM. We need to
land some logic in `rules_nodejs` first that would allow an
ESM variant of `@angular/compiler-cli` to work.
Once this happened and there is a new release, we can re-enable
the test and make adjustments for v13 APF (i.e. running the linker
plugin when creating the rollup bundles).
PR Close#43431
This commit temporarily disables the SystemJS upgrade e2e tests. All of
the upgrade e2e tests (except for `phonecat-1-typescript`) rely on UMD
bundles. These are no longer available for the v13 Angular package
output, so we disable the tests for now.
These e2e tests can be re-enabled once we migrated the exampels from
UMD bundles to e.g. the CLI, or some custom rollup build. Alternatively
it might be even possible to use FESM bundles directly (depending on
browser support for the AIO examples; this is something the docs-infra
team will have to determine though).
PR Close#43431
With the APF v13 package output, deep files can no longer be imported.
Since we do not intend to bundle the compiler into the compiler-cli, we
need to switch all deep imports to the primary entry-point.
PR Close#43431
We updated the dev-infra version as part of the v13 package format
in order to be able to use the latest `rollup` version (and its
plugins). The update of the shared dev-infra package resulted in an
update of Chromium to a more recent version. This version of Chromium
seems to normalize the `content-type` header differently, so that the
AIO `http` example test assertion needs to be updated to work with the
new version of chromium. This commits updates the test.
PR Close#43431
Adding suites to the `IGNORED_EXAMPLES` array currently results
in an runtime exception because later when ignored examples are
printed to stdout, a non-existent variable is referenced back
from when there were examples disabled due to the Ivy migration.
This commit fixes the logic.
PR Close#43431
Updates the `hello_world_closure` integration test to use APF v13
in combination with the linker plugin which is needed as running
the `ngc` command standalone does not modify the `node_modules`
and the FW packages remain partially compiled. A step in between
using rollup can create a linker-processed bundle of all FW
packages.
PR Close#43431
Updates the dynamic-compiler test to be compatible with the APF v13.
As of v13, the packages no longer come with metadata.json files and
now need to be processed with the babel linker plugin. This commit
sets up the linker plugin, and switches away from the deprecated
systemjs approach to a simpler rollup code-splitting variant.
PR Close#43431
Invalidate the cache for node modules so that the CLI builds from
the snapshot repositories are used. Due to a bug in Yarn, and the need
of using the `github:<..>` syntax, the old artifacts from previous runs
are incorrectly cached. This could have been prevented by using an actual
full Git ref URL, but unfortunately that does not work because the CLI
devkit snapshot dependencies set snapshot builds as deps as well. The URLs
here need to match as otherwise Yarn will conflict. e.g.
```
Pattern ["@angular-devkit/core@github:angular/angular-devkit-core-builds#64b7e2b1d"] is trying to unpack in the same destination "/Users/paul/Library/Caches/Yarn/v6/npm-@angular-devkit-core-13.0.0-next.6/node_modules/@angular-devkit/core" as pattern ["@angular-devkit/core@github:angular/angular-devkit-core-builds#0e7277c63"]. This could result in non-deterministic behavior, skipping.
```
PR Close#43431
In the current Bazel setup, we run CommonJS as devmode output, and ESM
for prodmode output. This means that consumers of the
`@angular/bazel` package will end up using the prodmode-built ESM
package of the compiler-cli. This commit adds interop logic to be able
to load the compiler-cli as strict ESM package.
We cannot switch devmode to ESM, as this would require some changes
in `rules_nodejs` and potentially the reduction of both output flavors
into a single one (which is a future project anyway). This is out of
scope for now and inside g3, there is still devmode output as well.
PR Close#43431
Ngcc relies on cluster for distributing work. The master controller
sends messages to the workers as soon as the worker becomes `online`.
The online event is sent as part of the NodeJS cluster logic itself.
This does not work well because technically `online` could emit before the
worker started listening (this seems to be case now with ESM as the
imports are loaded in a way where `online` emits too early; before the
worker actually listens for messages).
We fix this by explicitly notifying the master when the worker
is ready for retrieving IPC messages/or tasks. This is more safe
anyway as it's not clearly specified when `online` emits.
PR Close#43431
Given that we ship all of compiler-cli and localize in ESM
mode now, we need to use a ESM compatible version of Yargs.
The latest version seems ESM compatible but with some small
API changes. This commit updates Yargs and updates the command
line option code to use the new API.
PR Close#43431
Updates the lock file resolution logic in ngcc to work with ESM output.
The compiler-cli is now shipped in bundles, so the actual module resolution
needs to stay to keep the lock file path consistent regardless of where the
lock file code is bundled into. The ngcc integration test needs to be updated
though since the `ngcc` entry-point will always reside in the `bundles/` directory
now.
It has been considered using the top-level `package.json` of the compiler-cli
package, but that caused problems in tests down the line because the ngcc
tests only have the `@angular/compiler-cli/ngcc/...` targets linked into
the node modules. It's not worth changing this and reworking tests if ngcc
is going away in the future anyway (+ it has been like that before!).
PR Close#43431
Switches the compiler-cli usage of `__filename` to `import.meta.url`
when ESM bundles are generated. Unfortunately we cannot start using
only `import.meta` yet as we still build and run all code in Angular
in CommonJS module output for devmode tests.
This commit also fixes various instances where a jasmine spy was applied on
a namespace export that will break with ES module (and the interop for
CommonJS output). We fix these spies by using a default import.
PR Close#43431
Removes the remaining usages of dynamic require statements in the
package output. Since we declare all shipped packages as strict ESM,
we cannot use dynamic require statements anymore. This commit switches
these usages to actual `import` statements.
Note: Tsickle continues to remain an optional dependency since bundling
does not work with its UMD package output. Also tsickle is rarely used by
consumers, if at all, so bundling does not really provide any significant
value. To continue keeping tsickle optional (since it's still needed by the
`annotateForClosureCompiler` option which is also respected in ngtsc), we
pass-through a tsickle instance as a parameter to `main`. This allows us to
keep the compile functions synchronous without having to refactor the majority
of the watch compilation code, and majority of tests for ngc, ngtsc.
Consumers (like the `ngc` bin entry-point) can then load tsickle based on their
module format. e.g. tsickle can be imported through `require` to keep everything
sync, but in ESM, the dynamic import can be used beforehand to pass `tsickle` to
the `main` function. We can revisit this in the future but for now this does the
trick without exceeding the scope of this commit..
PR Close#43431
As of v13, the package output will be using partial compilation output.
This breaks the Bazel setup similar to how it breaks Angular Components.
The problem is that `@bazel/concatjs` relies heavily on the UMD files
that previously existed in APF, plus it assumed that ngcc pre-processed
the files in the `node_modules`. This is no longer the case as there are
no UMD files, and the code is not fully-compiled by the Angular
compiler.
PR Close#43431
As outlined in the previous commit which enabled the `esModuleInterop`
TypeScript compiler option, we need to update all namespace imports
for `typescript` to default imports. This is needed to allow for
TypeScript to be imported at runtime from an ES module.
Similar changes are needed for modules like `semver` where the types incorrectly
suggest named exports that will not exist at runtime when imported from ESM.
This commit refactors all imports to match with the lint rule we have
configured in the previous commit. See the previous commit for more
details on why certain imports have been changed.
A special case are the imports to `@babel/core` and `@babel/types`. For
these a special interop is needed as both default imports, or named
imports break the other module format. e.g default imports would work
well for ESM, but it breaks for CJS. For CJS, the named imports would
only work, but in ESM, only the default export exist. We work around
this for now until the devmode is using ESM as well (which would be
consistent with prodmode and gives us more valuable test results). More
details on the interop can be found in the `babel_core.ts` files (two
interops are needed for both localize/or the compiler-cli).
PR Close#43431
Enables the `esModuleInterop` for all TypeScript compilations in the
project. This allows us to emit proper ESM-compatible code. e.g.
consider the following import:
```ts
import * as ts from 'typescript';
```
This import currently will break at runtime in NodeJS because the
`typescript` package is not shipping ESM. It's still a CommonJS module.
ES modules are able to import from `typescript` though, using an import
statement as above, but everything in `module.exports` is being exposed
as the `default` named export. TypeScript at runtime does not have any
other named exports, so for actual ESM compatibility, all of our imports
need to be switched to:
```
import ts from 'typescript';
```
The `esModuleInterop` option allows this to work even though the
`d.ts` file of TS currently suggests that there are _only_ named exports.
The TypeScript language service will now suggest the correct import form as
shown above. It doesn't enforce that unfortunately, but this commit also
adds a lint rule that enforces certain patterns so that we emit imports
that are compatible with both ESM and CJS output (CJS still needed here
since tests run with CJS devmode output still; this is a future project
to switch that over to ESM!)
PR Close#43431
This wires up the `@angular/localize/tools` entry-point. For context:
This entry-point is being created to avoid deep imports into
`@angular/localize/src/tools/<..>` like the CLI relies on. Deep imports
do not play well with strict ESM, and now that all APF packages are
strict ESM, the tool code needs to be either strict ESM as well.
We use ESBuild to create individual bundles for the CLI entry-points,
and the actual tool entry-point. We use a bundler because this enables
the localize code be ESM compatible. Without a bundler, all relative imports
within the `tools` entry-point would need to explicitly have the `.js`
extension. This would be cumbersome and hard to maintain/enforce or
validate.
One might wonder why this is not a standard APF entry-point then. The
answer is that the APF entry-points do not support exposing the CLI
binaries (like `yarn localize-translate`). This could be done through
tertiary entry-points, but using ESBuild directly gives us more control
for now. We might want to revisit this in the future again.
PR Close#43431
Moves the `src/tools` folder of the `@angular/localize` package into the
top-level of the package. This is in preparation of actually exposing an
entry-point for the tools that can be accessed using
`@angular/localize/tools`.
We want to expose such an entry-point because the CLI currently
deep-imports into various places of the tools, but this will not
work well with strict ESM because the localize tool depends on the
v13 strict ESM packages like the `@angular/compiler` or
`@angular/compiler-cli`.
PR Close#43431
The CLI has been updated with various changes to support for ESM package
output of the framework. This commit updates to a next version of the
CLI v13 that contains these necessary changes, allowing us to test/validate
our package changes through integration tests or AIO examples.
This update also contains a fix for the adjust enum babel optimization
that broke with the latest rollup version.
PR Close#43431
Temporarily disables the `components-repo-unit-tests` job due to APF
v13 which is currently not handled properly in the components repo. The
components repo would need to be updated first to properly handle v13
APF output (with linker processing and an alternative to UMD bundles
which the majority of tests currently rely on).
PR Close#43431
As part of v13, all APF packages use the `exports` field which defines
the public entry-points/mappings for a package. so-called package exports.
The `ng_package` rule creates all the necessary mappings/sub-path exports
for the entry-points of `@angular/common`. Though, since the locale files are
generated separately and are not an actual entry-point, we need to expose these
files publicly so that they can be imported/resolved by consumers.
PR Close#43431
We switched the build output for the compiler-cli to use esbuild-generated
bundles.
This means that actual devmode ES5 sources, or prodmode ES2020 non-bundled
sources are not actually needed. Only the types are needed, and this commit
makes sure only the type definitions are shipped. This reduces the code size
of the compiler-cli and also helps with avoiding incorrect module resolution.
PR Close#43431
Updates the service-worker package to export the worker script and
schema, so that these files can be resolved and included by consumers.
Additionally, the CLI bundle is updated to be using ESM as it
transitively relies on the `core` entry-point of the package which
already uses ESM. Also this is required because the script is part
of the the service-worker package which has `type: module` applied.
PR Close#43431
Similar to other code that is shipped as part of `@angular/common`
(with APF v13), we should ship the generated locale files as ESM
files as well. This is necessary/reasonable because we explicitly
set `type: "module"` for the common package, so it makes sense to
have the same apply for the locale sub-directory.
Note: The global locale scripts remain having the `.js` extension
and will continue to be unmodified. They are CJS/ESM compatible either
way, but refer to browser globals.
PR Close#43431
Updates the `sideeEffects` field in `package.json` files to reflect the
new APF v13 format where files use the `.mjs` extension, and are located
in new directories (like the `fesm2020` folder).
PR Close#43431
Sets the executable bit for the build-packages-dist script so that
the script can be invoked directly without having to explicitly
prefix it with the `node` command.
PR Close#43431
Updates the platform-server integration test to rely on the v13 partial
compilation packages. This involves setting up the Babel linker plugin.
This is a great addition for coverage of the Babel linker plugin.
PR Close#43431
The view engine language-service tests currently rely on the `npm_package` output
that is built locally. They rely on the package output mostly for
compiling test scenarios (with dependencies on e.g. forms), and for
the testing the metadata extraction (testing proper suggestions for VE).
The reliance on these packages becomes problematic with the new Angular
Package Format v13 where no metadata files are shipped. To continue
being able to test View Engine language-service compatibility, we will
use the v12.x framework packages for some of the test scenarios.
PR Close#43431
This just came up while working on an integration test that also
relies on RxJS v7. It looks like the RxJS package has not been pinned
for the v7 test, so that the test actually always ran v6 by accident.
This commit fixes that.
PR Close#43431
In order to support ESM for the `platform-server` package, we need to
remove two usages of dynamic imports and replace them with their
corresponding/equivalent import statement. This will also allow ESBuild
to recognize this import. Note that we want to keep these imports external, so
we explicitly specify the `externals` option for the `ng_package` rule.
PR Close#43431
The bazel integration tests are currently not compatible with Windows.
Tests never get to run because the created tar packages for NPM packages
are built using an outdated `pkg_tar` rule that creates invalid
tarballs. We fix this by using the non-deprecated windows-compatible
`rules_pkg` implementation.
Additionally, we copy all `package.json` files of integration tests to
the bazel bin directory as otherwise the file would be accidentally
modified as a source on Windows.
PR Close#43431
Technically this change would not be needed as the NPM package
output is always built with Ivy now (using the transition). There
is no View Engine output anymore. We still want to limit the tests
to only run with the `--config=ivy` define setting as some API goldens
tests could accidentally rely on plain `ng_module` output / additionally
we wouldn't need to run the API golden tests multiple times.
PR Close#43431
The View Engine ngc tests currently rely on the `npm_package` output
that is built locally. This becomes problematic with the new Angular
Package Format v13 where no metadata files are shipped. To continue
being able to test View Engine compilation, we will use the v12.x
framework packages for running the View Engine test.
Note: This means that we no longer test metadata extraction directly
for our framework packages, but given that any change to View Engine
will still land in patch, where the VE packaging still occurs, we should
be covered here.
PR Close#43431
Basic integration tests are those which do not require significant
changes as others. The larger ones will have individual commits.
For v13, the NPM package output will always be using partial compilation
output. This makes the ngcc integration test fail because the actual
Angular framework packages are no longer processable. We fix this, and
keep the ngcc test coverage by relying on the v12.x framework packages
in the integration test.
The terser integration test needs to point to the new Flat ESM module
file location. We now output FESM2020 instead of FESM2015. This also
requires us to use the latest version of terser.
The `side-effects` test currently is not maintained by us and relies
on View Engine build output. In the partial compilation output the
partial declarations are not marked with `@PURE` and are not removed
therefore. We would need to update the side-effect test to use the
linker Babel plugin instead. This is currently out-of-scope though
so we disable the test for now.
PR Close#43431
ngcc currently dynamially loads the `Transformer` code. It does this
to avoid unnecessary parsing and loading of transformer-related code
if there is nothing to process (so-called noop case). Unfortunately
this dynamic require is not recognized by ESBuild. The import needs
to be discovered as otheriwse the transformer code would not be included
in the bundled package output of the CLI.
The ngcc code needs to use an async runtime import as it would work
in ES modules. This introduces async code into to the compililation
pipeline, breaking the `ngccMain` synchronous invocation feature.
To avoid this, we just move the dynamic require/async import to
the file top-level so that we do not break synchronous processing
which the CLI relies on. This has the downside of slowing-down
the noop case a little but I believe that should be mitigated
through bundling of ngcc anyway. In the future with full-ESM
we won't be able to get around this anyway (unless we remove the
sync variant of ngcc processing).
PR Close#43431
Exposes code needed by the Angular CLI. Previously the CLI used
deep imports for most of these things, but now with bundling
the CLI, we no longer support deep imports.
We will expose the necessary dependencies for the linker as part
of the primary entry-point (I think that is more maintable than
re-exporting them as part of the linker). We also expose the ngcc
entry-point for the CLI with a new constant that will point to the
ngcc command line entry-point (which the CLI relies on).
PR Close#43431
