We modified the macros of `nodejs_binary/test` to have a rule
in between that requests the `.mjs` output. This works fine but
breaks make variable substitution for `templated_args` because
Bazel requires referenced labels to be part of the explicit `data`.
The rule in between breaks this, so we add a new argument that
can be used for such "template"/"args" data dependencies.
This can be removed when everything is ESM and we don't need
the rule in between.
PR Close#48521
The `nodejs_binary` rule already prioritizes the `.mjs` output as
of the recent commits. The `nodejs_test` rule should do the same,
and also set `use_esm = True`
PR Close#48521
The Bazel NodeJS rules will always use the `.js` files as entry-points.
Since we only rely on the `.mjs` output going-forward, we need to teach
`nodejs_binary` and `nodejs_test` to use the `.mjs` extensions if
intended.
Our `defaults.bzl` macros will set `use_esm = True`, but other targets
from e.g. external repositories should keep the original behavior.
PR Close#48521
Replaces the existing ESM loader for dealing with external module
imports. This loader was introduced by Aspect for AIO `.mjs` scripts.
The loader will be used as foundation for a more extensive loader
that also properly handles first-party packages.
Additionally another loader is added, all packed as a single
loader because our current NodeJS version only supports a single
loader per node invocation. So we implement chaining ourselves.
The new loader will attempt rewriting `.js` extensions to `.mjs`,
also it will add `.mjs` if not already done. This is necessary
in the transition phase because we don't/cannot use explicit `.mts`
extensions and also we don't specify extensions in imports yet.
Long-term we would likely use `.mts` and explicit import extensions,
but it's not yet clear how we would sync this into g3 too.
PR Close#48521
This is in prearation for having a proper diff when this loader
is adjusted to support more situations than just simple external
node modules. See next commit.
Also the file is formatted to make the diff less verbose later.
The file was never formatted correctly and we don't lint `.mjs` files.
PR Close#48521
Currently the devmode output for `ng_module` and `ts_library` is
using ES5 CommonJS UMD. To bring it in sync with prodmode and
to start with our long-term migration to full ESM- the devmode
is updated to to ES2020 ES modules too.
This will require more tricks to make devmod work with the bazel
setup and also tests may need to be refactored given them relying
on ES5 CJS features, like for `spyOn` jasmine patching etc.
PR Close#48521
Similar to the Rules NodeJS require patch, we have an ESM import patch
as of the AIO Bazel migration (to support ESM scripts better).
This script uses `--loader`, an experimental NodeJS flag. This is
similar to how `ts-node` uses it. We should disable the warnings
as it results in a lot of unreadable Bazel output and the warnings
are okay to be ignored. Note that we cannot fine-grain disable
the specific warning so all others would be disabled too.
Realistically we haven't seen any in the past and long-term we will
be not relying on patched resolution anyway (looking at `rules_js`).
PR Close#48282
Temporary patch until
https://github.com/bazelbuild/rules_nodejs/pull/3517 is available in
another `rules_nodejs` release.
We can remove this patch, but for now it doesn't hurt. On the external
side the tsickle code path is not hit at all anyway, but we need to
satisfy the TypeScript checker.
PR Close#47018
The dev-infra build tooling is now decoupled from `ng-dev`. This will
make it easier to update `ng-dev` without necessarily needing to upgrade
the whole build system, Bazel etc. This is useful when e.g. new release
tool features have been added and should also be ported to active LTS
branches.
PR Close#46976
The JS size-tracking logic has been moved into the dev-infra repository
and the rule has been updated to work better with Bazel labels. The
Starlark target is updated accordingly in this commit.
PR Close#46802
This script was used back when dev-infra code was part of
the Angular framework repository. The script is now unused
and can be deleted.
PR Close#46798
The jasmine seed generator is only used in a single karma configuration
file. Used by the legacy build and the Saucelabs/ZoneJS Karma jobs.
We should move the separate script code directly into the config to make
it clear that the seed generation is not used elsewhere, and to simplify
the Starlark code.
PR Close#46798
The `app_bundle` rule from the shared dev-infra package is no longer in
the benchmarking folder, but instead is part of the general Bazel rules
exposed by `dev-infra`. This commit accounts for this location change.
PR Close#46642
tsec previously did not use runfiles on Windows even when the flag was enabled.
The latest version now adds an option to force its usage.
PR Close#46447
Patches are required for tsec and rules_webtesting. The fix for
rules_webtesting was merged to that repo
(581b1557e3)
but it's unclear when a release will be cut.
PR Close#46313
The NodeJS Bazel linker does not work well on Windows because there
is no sandboxing and linker processes from different tests will attempt
to modify the same `node_modules`, causing concurrency race conditions
and resulting in flakiness.
PR Close#45872
Speeds up the dev-turnaround by only bundling types when packaging. Currently
bundling occurs for all the `ng_module` targets in devmode.
This has various positive benefits:
* Avoidance of this rather slower operation in development
* Makes APF-built packages also handle types for `ts_library` targets consistently.
* Allows us to ensure APF entry-points have `d.ts` _always_ bundled (working with ESM
module resolution in TypeScript -- currently experimental)
* Allows us to remove the secondary `package.json` files from APF (maybe APF v14? - seems
low-impact). This would clean-up the APF even more and fix resolution issues (like in Vite)
PR Close#45405
As part of the devtools migration, we copied the custom http server/
dev-server from the `angular/components` repo. This server implementation
has now moved to the shared dev-infra code, and we can clean up the
copy in this repository now.
PR Close#45452
As mentioned in previous commits (check them for more details), `@bazel/typescript`
no longer contains `ts_library`-specific code, so we no longer need that dependency.
PR Close#45431
Update `@bazel` packages to the latest 5.x version.
Some of the changes here are modeled after
angular/dev-infra@40c0ac8559.
Co-Authored-By: George Kalpakas <kalpakas.g@gmail.com>
PR Close#45431
Node.js v12 will become EOL on 2022-04-30. As a result, Angular CLI v14 will no longer support Node.js v12.
BREAKING CHANGE:
Support for Node.js v12 has been removed as it will become EOL on 2022-04-30. Please use Node.js v14.15 or later.
PR Close#45286
Switches the Karma web test rule from `@bazel/concatjs` to our
wrapped/extended variant from the shared dev-infra code.
One benefit is that we now get a `_debug` target for web tests where
no browser is being launched and the action is kept alive. Allowing
developers to conveniently connect a browser manually for debugging.
Also works with iBazel for the manually connected browser.
PR Close#45117
Previously with ESBuild 0.14.11, when a file had dynamic requires to
builtin NodeJS modules like `url`, the resolution completed successfully
regardless of `--platform browser`. This seems to be fixed in ESBuild now.
This unveiled some resolution errors with our Saucelabs bundle generation
because the framework code sometimes switches dynamically to `require('url')`
if `window.URL` is not defined. Previously this just didn't matter, but now
the `require('url')` is checked and a module resolution error is reported given
`url` not being available in the browser as a builtin module.
We fix this by marking the module as external. We will not hit this code path
anyway in the browser saucelabs code. Similarly we exclude all platform-server
files from the bundle. This is not strictly needed after the `url` module being
marked as external, but the issue showed that lots of unnecessary code for the
server platform is included. This can be omitted (unfortunately not from the TS
compilation without over-complicating things significantly more; experimented with
that).
PR Close#44830
Updates the postinstall patch for the benchmark macro rule from dev-infra.
We moved the ZoneJS setup to the bundler. This was necessary in order to
switch away from the Go-based (windows-incompatible, m1-incompatible)
concatjs devserver to a rather basic HTTP server (also provided by dev-infra now).
PR Close#44830
Previously devtools used a nested workspace for its bazel configurations. This meant framework dependencies were consumed via npm.
Now devtools is part of the root bazel directory that all other files in this codebase fall under. This allows us to build devtools using local angular packages, removing the need to consume these dependencies with npn. This is useful because we no longer have to update these dependencies with an automated tool like renovate, and our CI tests will always run against the most up to date framework packages.
To make our test output i.e. devmode output more aligned
with what we produce in the NPM packages, or to be more
aligned with what Angular applications will usually consume,
the devmode output is switched from ES5 to ES2015.
Additionally various tsconfigs (outside of Bazel) have been
updated to match with the other parts of the build. The rules
are:
ES2015 for test configurations, ES2020 for actual code that will
end up being shipped (this includes the IDE-only tsconfigs).
PR Close#44505
The `ng_rollup_bundle` rule has been replaced with a new rule called
`app_bundle`. This rule replicates the Angular v13 optimization
pipeline in the CLI, so that we can get better benchmarking results.
Also the rule is much simpler to maintain as it relies on ESbuild.
The old `ng_rollup_bundle` rule did rely on e.g. build-optimizer that no
longer has an effect on v13 Angular packages, so technically size
tests/symbol tests were no longer as correct as they were before. This
commit fixes that.
A couple of different changes and their explanation:
* Language-service will no longer use the benchmark rule for creating
its NPM bundles! It will use plain `rollup_bundle`. ESBuild would have
been nice but the language-service relies on AMD that ESBuild cannot
generate (yet?)
* Service-worker ngsw-worker.js file was generated using the benchmark
bundle rule. This is wrong. We will use a simple ESbuild rule in the
future. The output is more predictable that way, and we can have a
clear use of the benchmark bundle rule..
* A couple of benchmarks in `modules/` had to be updated to use e.g.
`initTableUtils` calls. This is done because with the new rule, all
files except for the entry-point are considered side-effect free. The
utilities for benchmarks relied on side-effects in some
transitively-loaded file (bad practice anyway IMO). We are now
initializing the utilities using a proper init function that is
exported...
PR Close#44490
We are in an inconvenient situation where the ng-dev package might rely
on packages from the Angular framework repository. Given that we install
this package in the framework repository, we need to update some
references through a postinstall.
This commit updates the patches to account for the latest changes in the
dev-infra package/repository.
PR Close#44490
