Using 'always' as the stamp attribute caused stable-status.txt
to always be included as an input, which has different values on
different ci executors causing a cache miss.
We run the regular aio build without stamping on ci so only include
status files when stamping is explicitly enabled.
PR Close#48585
The Karma Saucelabs script for Bazel & Saucelabs relies on some CommonJS
specific features. This commit replaces it with an ESM-compatible
alternative so that it can execute because `nodejs_binary` requires ESM
files now.
PR Close#48573
With the recent ESM changes we also started generating Saucelabs
targets for `//devtools` (as part of an effort to avoid code
duplication). We should skip Saucelabs targets for this package
because we don't intend to run them on Saucelabs and this whole
setup needs some more work (and we shouldn't change unexpectedly).
PR Close#48554
The way the benchmarking code is used and wired up in g3 is rather
magical. This change makes it easier to sync into g3 by using
conditional blocks, and also consistnetly using a single bundle name
(like it was before— we regressed here as part of the ESM initial
changes- but now with clear comments, it's more future-proof..)
PR Close#48521
Fixes that we temporarily broke the Bazel npm package artifact as
part of the ESM work. This commit adjusts it and also makes the
artifact subsitutions more maintainable.
PR Close#48521
This will help making it easier to update patches when `node_modules`
are cached. Note that most of the time this shouldn't be necessary
as we only cache the Yarn `.cache` for the non-windows jobs. Windows
job caches `node_modules` directly- so could be affected and needs
a cache reset/wipe occasionally when patches change (even though it's
rarely). Long-term we can remove this when the esm patches are no longer
needed.
PR Close#48521
This is basically a pre-step for combining devmode and prodmode into a
single compilation. We are already achieving this now, and can claim
with confidence that we reduced possible actions by half. This is
especially important now that prodmode is used more often, but rules
potentially still using the devmode ESM sources. We can avoid double
compilations (which existed before the whole ESM migration too!).
We will measure this more when we have more concrete documentation
of the changes & a better planning document.
Changes:
* ts_library will no longer generate devmode `d.ts`. Definitions are
generated as part of prodmode. That way only prodmode can be exposed
via providers.
* applied the same to `ng_module`.
* updates migrations to bundle because *everything* using `ts_library`
is now ESM. This is actually also useful in the future if
schematics rely on e.g. the compiler.
* updates schematics for localize to also bundle. similar reason as
above.
PR Close#48521
* Switches all remaining targets (even if not tested and failing as per
build) away from `ts_devserver` to the canonical `http_server` from
dev-infra.
PR Close#48521
ZoneJS is no longer loaded as an UMD, but instead is included as part
of the browser init entry-point. This means that ZoneJS is bundled and
the ESBuild logic needs to be adjusted for that.
PR Close#48521
After discussion initiated in the framework team (by kkostadinov),
the team has decided to not keeping the `components-repo-unit-tests`
job. This commit removes it.
PR Close#48521
* The benchmark macro should also use devmode ESM 2020. No CommonJS
* The benchmark macro should always add `benchpress` as runtime
dependency because it is loaded asynchronously.
* The protractor `nodejs_binary` should use our ESM-interop binary
so that ESM resolution works (e.g. when `await import(benchpress)` from
the driver utilities is invoked).
PR Close#48521
* Switches away from the ESM-incompatible & unmaintained `ts_devserver`
to `http_server`. This is the canonical server maintained by dev-infra
* Switches tests away from CommonJS specific logic. e.g. require.resolve
* Adjusts tests to work with Protractor spec bundling (Protractor does
not support ESM execution, but we want to take ESM-written specs)
* Reworks playground and benchmarks to use `app_bundle` and `esbuild`
instead of loading hundreds of files individually. This also makes
tests more stable and more aligned with real applications.
PR Close#48521
* Updates circular dependency tests to use the `.mjs` outputs
* Switches away from CommonJS specific `require` calls.
* Simplifies the test helper logic since all browsers/NodeJS versions
support `URL` as a global.
PR Close#48521
The Angular Language Service package is now tested & compiled using ESM.
Previously it was a mismatch of CommonJS and ESM.
Still the language-service ESM output is transformed into a single UMD
bundle to allow for module resolution to be overriden. See
`bundles/BUILD`.
This is kept as is. To fully ship ESM (language-service is an exception
here), we need to:
* Update all code to no longer reference typescript via import. Instead
typescript needs to be passed around so that the extension can
control the version
* The VSCode extension/ the TS server needs to be able to load ESM. It
looks like the server supports ESM global plugins, but the extension
might not yet.
This is out of scope for the dev-infra effort as it requires more
insight into VSCode & the extension system & the TS language server.
PR Close#48521
* The Karma Bazel Saucelabs binary needs to use `.mjs` as everything in
the repo w/Bazel is supposed to be ESM.
* The symbol extractor test is updated to no longer use CommonJS
features like `require.resolve`.
PR Close#48521
* Switches all examples to use dev-infra's canonical ESM-compatible
`http_server`.
* Uses ESBuild for bundling ESM into a single file, compared to having
to load hundreds of individual ESM files in the browser (potential
source of flakiness & slowness).
PR Close#48521
Since the `defaults.bzl` repo-wide macros are now supporting ESM,
the special spec-bundle logic from `devtools` can be removed.
Also the esbuild configurations need to be updated to account
for the recent dev-infra build-tooling changes. Also properly
now ensures that `aysnc/await` is downleveled for ZoneJS compatibility.
PR Close#48521
* Updates build-tooling to benefit from the latest `spec_bundle`
improvements.
* Updates the ESM extension loader to not attempt adding extensions to
builtin `node:` specifiers. This seems to be disallowed and cannot be
handled gracefully (the attempts are part of a try/catch).
```
Use --sandbox_debug to see verbose messages from the sandbox
Error [ERR_UNKNOWN_BUILTIN_MODULE]: No such built-in module: node:fs.mjs
at new NodeError (node:internal/errors:371:5)
at ESMLoader.builtinStrategy (node:internal/modules/esm/translators:276:11)
at ESMLoader.moduleProvider (node:internal/modules/esm/loader:236:14)
```
PR Close#48521
Since the Bazel setup in this repo will now always use ESM,
the tooling scripts/binaries in AIO need to be switched to ESM
too. Most of the scripts are already ESM, but a few had to be converted.
Note that the Dgeni generation does not use ESM because it's unaffected
and the Dgeni CLI is used. In the future we could also update the Dgeni
setup to ESM but there is no need currently.
PR Close#48521
Even with patched resolution, we should always attempt the next/builtin
NodeJS resolution first. It may find a module if there `node_modules`
relative to the context file. This would be more correct than looking
for a module always at the Bazel `npm` repository `node_modules` folder.
PR Close#48521
ESBuild relies on the linker and we currently set up the ESM loader,
along with accidentally enabling the patched resolution loader. This
didn't cause any problems in sandbox, but outside of sandbox incorrect
ESBuild versions may be discovered because the loader looks at the
top-level `npm/` node modules before looking relative to e.g.
`@bazel/esbuild`
PR Close#48521
* Adjusts tests to no longer rely on CommonJS features. Switches them to
ESM
* Updates test initialization files to not double-initialize Jasmine now
that bootstrap files are loaded after Jasmine. The `jasmine.boot`
setup was hacky from `rules_nodejs` and will break in the future
regardless if we e.g. use `rules_js` with actual unmodified `jasmine`.
PR Close#48521
Tests now always run with ESM 2020, while previously they ran with
ES2015 CommonJS UMD bundles.
Since ZoneJS does not support intercepting native `async/await` syntax,
the forms test needs to use the zone-compatible variant of
`jasmine_node_tests`. This variant downlevels the native `async/await`
syntax to generators that ZoneJS can intercept. All of this is done
using the dev-infra ESBuild `spec_bundle` rule.
PR Close#48521
* Uses `.mjs` for circular deps tests
* Replaces `require` with ESM-equivalent. uses an import statement here
for proper typing, and specify dependency properly.
PR Close#48521
The `packages/localize` package still required some trickery
to support CommonJS because tests in the repo were running as CommonJS.
This commit removes the CommonJS logic in localize and its tests, so
that only ESM is used in production & tests.
PR Close#48521
Protractor does not support ESM, so we need to take all the ESM
output and bundle it into a CommonJS file. This comes at the cost
of not using actual ESM for execution, but the ESBuild bundle follows
strict ESM semantics so we can be sure it's compatible when we have
an ESM-compatible e2e test runner in the future.
PR Close#48521
There are two build targets which never had all its runtime dependencies
properly specified. This wasn't noticed because there were macros in
`defaults.bzl` that automatically included these deps.
In a follow-up we will clean-up this legacy auto-deps feature in
`defaults.bzl`.
PR Close#48521
The ESM js files need to be referenced, and the router tests rely
on `async/await` with change detection- so a special rule is required
that downlevels `async/await` to generators (similar to the Angular CLI)
PR Close#48521
Introduces a variant of `jasmine_node_test` that works with async/await
in combination with ZoneJS. This is needed for tests relying on
async/await in combinatin with change detection.
Browser tests are already benefting from ESbuild async-await
downleveling. Node tests would ideally not need this, but until
ZoneJS supports native async/await we need to also process
source files to avoid native async/await syntax.
PR Close#48521
* Switches to the canonical dev-infra http server
* Uses the bundle for serving.
* Switches app_bundle to simple `esbuild` since the test relies
on `ngDevMode` which `app_bundle` elides as optimization.
PR Close#48521
`platform-browser` tests now run in ESM and with `.mjs` output, so
the build targets and tests need to be updated.
Here we change the `zone_event_unpatched` script to include the
`.init` suffix that will be picked up by `spec_bundle`.
Also some circular dependency tests are updated to refer to the
`.mjs` files.
PR Close#48521
The bazel tests cannot use CommonJS features like `require` and should
be updated to work with ESM. Additionally some specs are updated to
no longer assert CJS/UMD output from `ng_module`. The rule only emits
ESM now.
PR Close#48521
The Angular CLI does not yet support schematics running as ESM. For
this reason we switch the schematics BUILD targets to explicitly
use ESM (as an exception in the repo).
PR Close#48521
Since Karma with Bazel does not support ESM natively, we bundle the
tests using ESBuild into a single AMD file. This not only solves the
ESM issue until we can run browser ESM tests natively (also pending
in the components repo - the esbuild generation follows ESM semantics
but since collapsed we don't rely on the real module system).
A benefit of bundling is also faster and more reliable Karma browser
tests since only a single file needs to be loaded- compared to hundreds
of individual files.
PR Close#48521
If tests are bundled using e.g. esbuild, the `ee` symbols may
be rewritten to `\u0275\u0275`. This breaks assertions that
rely on `Function.toString`. We can avoid this string comparison
and make it more future proof by just comparing the symbols directly.
PR Close#48521
Update dev-infra's build-tooling since multiple ESM changes have
landed there. e.g. not relying on `require.main === module` for API
bundling. This will allow us to also execute all dev-infra rules
in ESM because we plan on applying our ESM patching to `ts_library`
(which would also affect build-tooling then).
PR Close#48521
Alan Agius