This option has no longer any effect as Ivy is the only rendering engine.
BREAKING CHANGE: Angular compiler option `enableIvy` has been removed as Ivy is the only rendering engine.
PR Close#47346
We currently use all the ESM2020 and type sources as inputs for rollup
and type bundle actions, respectively. This is a source of slowness in
Bazel sandboxed builds because many unused files will be linked/made
available for many concurrently-running actions.
We should limit the inputs only to what is assumed to be used. We cannot
know exactly and need to include transitive types from `node_modules`,
but that is an inevitable construct with the current Bazel rules.
Note that the external node modules could still bring in a lot of files,
like in Material where the `.d.ts` files for all locales are brought
into the sandbox (from `@angular/common`). We likely would need to
remove these files in a postinstall for now, to speed up actions,
similar to how we did it for RxJS in all repositories. These are known
to be not used in the components repo.
PR Close#46187
Call tsc_wrapped's fileExists function instead of TypeScript's.
tsc_wrapped (used internally by ngc-wrapped) has an optimization under
bazel to avoid file system calls where possible. It takes advantage
bazelOpts.allowedInputs, which contains a list of all files available
for compilation.
File system calls can be quite slow depending on the file system. In
google3 I saw a 38 seconds compilation, which spent 6 seconds just doing
fs.stat calls during module resolution. Those fs.stat calls are entirely
gone after with this change.
PR Close#46069
We recently updated Babel and the Bazel types but this actually
resulted in duplicates, causing differences between what people
seen in their IDE vs. what Bazel builds.
This commit removes the lock file and generates it fully fresh,
deduping dependencies and also fixing the differences between
local IDE and Bazel.
As part of this we also need to update/fixup one assertion on the
Babel node path types, because the node start/end can now also
be `undefined`.
PR Close#45967
This change adds the capability of ngc_wrapped to emit an
unused_inputs_list file that could be used by starlark.
We are making this change because in situations where angular modules
depend on angular modules, it becomes very easy for a single change to
trigger a long cascading set of angular builds since each angular rule
depends on the transitive closure of input files.
With this change in place, and once it is properly configured, bazel
will update the set of inputs to a build rule after it is built once
removing any of the inputs specified in this list, making incremental
builds quicker by skipping any rebuilds that only had changes to unused
inputs.
This logic should be, and is likely duplicated in tsc_wrapped to solve
the same problem in pure TypeScript situations, ideally we could use the
same implementation one day.
In addition, its possible that tree artifacts are not as supported as
we'd like, and where this change should mark entire directories as
unused, we may get better performance gains by enumerating the directory
and being more explicit about specific inputs which are unused.
PR Close#45946
Speeds up the `d.ts` bundling by configuring it as a Bazel
persistent worker. Also improve logging for the ng packager
rule to make it easier to spot which actions/bundles take
up significant time.
Type bundling will occur for every entry-point so for machines
with rather limited cores/threads, this will be useful to save
NodeJS boot and resolution time.
PR Close#45900
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
We recently refactored how the ng package rule deals with static files.
As part of this refactoring, transitive files outside of the current
Bazel package were flagged as errors, while previously this was just
ignored. We need to revert back this behavior (even though code remains
much simpler and predicable now) since sass library targets for example
reference all transtive files in the default info and break packages then
PR Close#45622
Fixes the dts bundling by accounting for recent API extractor changes
which made API-extractor support path mappings. This causes
cross-package and cross-entry-point imports to no longer be considered
external, resulting in the imports to be dropped.
PR Close#45470
Looks like there is some old legacy code for extracting files
from NPM packages. This is already captured by the unscoped
ESM2020 output extraction.
PR Close#45470
Non-JavaScript source-providing targets in the `ng_package` rule can throw-off
the entry-point detection and therefore should be flagged. Currently e.g.
a genrule-generated static file might unnecessarily cause additional
actions to be generated (non-breaking but just unnecessary)
PR Close#45470
Currently the `ng_package` rule does not support generated
`package.json` files. Generated `package.json` files are sometimes
useful when e.g. dependencies are automatically inserted (e.g.
many dependencies in the components repo for the MDC deps)
Currently the `package.json` files would be copied as part of
the `data` attribute, but they would not be processed. i.e. missing
out on the `exports` field and more.
We can simplify the rule attributes and make this more ergonomic.
PR Close#45470
We updated buildifier and a few warnings became errors now. This commit
cleans up the failing unused variable instances, making the linter happy.
Additionally for the API extractor BUILD file, the package defaults
need to move to satisfy buildifier.
PR Close#45431
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
`@bazel/typescript` code moved to `@bazel/concatjs` for the tsc-wrapped code.
Note that this code is likely going to be removed anyway soon when we
move dts bundling from `ng_module` to `ng_package`.
PR Close#45431
Previously `tsc-wrapped` which is the foundation for `ngc-wrapped`, resided
in `@bazel/typescript`. It has been moved to `@bazel/concatjs` in rules_nodejs
so we need to account for that as part of our rules_nodejs v5 update.
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
.substr() is deprecated so we replace it with functions which work similarily but aren't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
PR Close#45397
The Bazel NodeJS rules provide two ways of accessing node modules:
* A linker which creates a `node_modules` directory in the execroot/or in the runfiles.
* A patched module resolution where no node modules directory necessarily needs to exist.
The first is the default in `rules_nodejs` and the second is technically the most idiomatic
resolution mechanism in Bazel (as it matches with a runfile resolution library).
The linker is prone to race conditions in persistent workers, or non-sandbox environments (like
windows). This is because the linker for all workers will operate on a shared `execroot` directory
and the same `node_modules` directory is modified all the time / potentially conflicting with other
linker processes from other concurrently-running workers.
We rely on the patched module resolution anyway, but just need to disable the unused linker to avoid
issues like the following:
```
---8<---8<--- Start of log, file at /private/var/tmp/_bazel_splaktar/280f06d55552a0d01f89f0955b5acd78/bazel-workers/worker-8-TypeScriptCompile.log ---8<---8<---
[link_node_modules.js] An error has been reported: [Error: ENOENT: no such file or directory, unlink 'node_modules'] {
errno: -2,
code: 'ENOENT',
syscall: 'unlink',
path: 'node_modules'
} Error: ENOENT: no such file or directory, unlink 'node_modules'
---8<---8<--- End of log ---8<---8<---
INFO: Elapsed time: 12.796s, Critical Path: 5.39s
INFO: 645 processes: 477 internal, 12 darwin-sandbox, 156 worker.
```
PR Close#45393
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
This commit finishes the removal of View Engine from the codebase, deleting
those pieces of @angular/compiler which were only used for VE.
Co-Authored-By: JoostK <joost.koehoorn@gmail.com>
PR Close#44368
The generated metadata is obsolete now that ViewEngine is no longer
used, so this commit removes the generation of those file from
`ngc_wrapped`. This is needed to allow removal of the metadata collector
in a subsequent commit.
PR Close#44269
The APF v13 `ng_package` rule will generate the `exports` field if not
set. Currently it allows for additional subpath entries to be configured
manually. The packager does not allow for custom conditions in subpath
exports which are auto-generated.
This is sometimes useful and necessary though. e.g. in Angular Material,
we also need to expose the index Sass file through a `sass` conditional
that the Webpack Sass loader will pick up. For this, the packager needs
to support manual additional conditions (as long as they do not
conflict).
PR Close#43764
In addition to the existing `exports` conditional exports we ship
as part of APF v13, we want to expose the non-bundled ESM2020 output
through the `esm2020` conditional name. Additionally we will expose
the flat ES2020 files through the `es2020` conditional field, allowing
consumers (like the CLI) to prioritize certain formats.
e.g. consider the case with RXJS where it currently defaults to
the ESM5 output. The CLI could now set `es2015` as the conditional
to leverage the ES2015 output of RXJS. This unveils a problem though
since this would also mean that `ES2015` output of the framework Angular
packages would be used instead of the available ES2020 output. Here is
the additional `es2020` conditional helpful as it allows the CLI to
prioritize `es2020`, fallback to `es2015` and lastly fallback to `default`.
if none do match for a certain package.
PR Close#43740
Currently when `ngc-wrapped` runs in external/consumer workspaces, like
in the Angular Components project, the `ngc-wrapped` binary relies on
the linker due to the patched module resolution in `rules_nodejs` no
longer being default. The reliance on the linker of `rules_nodejs` is
problematic for workers as the required `node_modules` are not
re-linked for every build. This was previously not an issue before the
APF v13 changes because the `compiler-cli` module was loaded only once
through an import statement.
As of APF v13, the compiler-cli module is loaded dynamically for every
build. This dynamic import can then break as the worker does not
initially load the compiler-cli module when becoming online. Instead,
the module is loaded on the first build where the node modules might not
be linked properly anymore (due to e.g. other targets running at the same time).
We fix thi issue by doing the following things:
1. Enabling the patched module resolution for consumer/external
workspaces. This would match how we use ngc-wrapped inside FW as
well.
2. Caching the compiler CLI module. Instead of re-fetching the module
through dynamic imports for every build (in a worker), we should use
the cached version. This is semantically the same as with APF v12
where a single import statement at file top-level was used.
Technically, NodeJS should cache the module, but it doesn't hurt
directly caching it as the module resolution will be patched by
`rules_nodejs` and could perform unnecessary tasks.
PR Close#43690
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
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
The Angular Core and localize package currently use deep imports for
code that is shipped. This is problematic as we want to ship the
compiler-cli as full-ESM. To achieve this we need to use a bundler and
this breaks deep imports.
We use a bundler for the compiler CLI because for full ESM
compatibility, we would need to explicitly add the `.js` extension
to all relative imports. This is very cumbersome and prone to mistakes
so to mitigate this problem in a safe way, we bundle the compiler-cli.
Note: Deep imports continue to exist for the language service as it
bundles the compiler-cli.
PR Close#43431
This commit implements partial compilation APF v13 for the
`ng_package` rule. The changes involve the following things:
1. Requesting the partial compilation output for all targets (and
its transitives) in the `deps` or `srcs` attributes.
2. Downleveling of ES2020 prodmode output to a FESM2015 file.
3. Cleanup of file resolution. Previusly, execroot file paths (which are
passed to the packager tool) were composed manually. This is prone to
mistakes and breaks with transitions.
A lot of this code can be simplified by passing the necessary Bazel
`File` information as JSON. This also simplifies the packager tool
significantly (and makes it more readable..)
4. Remoal of UMD bundles. This also allows us remove the `globals` rule
attribute with `externals` (we do not need any UMD global identifier
names anymore).
5. The `package.json` will set the `exports` field and use subpath
exports to make module resolution work for ESM consumers.
6. TSLib is also always set as `external` now. Previously it had to be
added as `dep` to the `ng_package` rule as UMD files bundled `tslib`.
7. The `include_devmode_srcs` option has been removed. This option was
an addition to APF that allowed the `@angular/compiler` to ship
non-flattened ES5 CommonJS sources. We want to keep APF consistent
and not allow such exceptions. Compiler is now a strict APF package
as well, and the compiler-cli just needs to go through the primary
entry-point for things it needs (or it bundles the necessary parts
into the CLI.)
Overall, these are all changes. A lot of changes to make the packager
rule and tool more readable and Bazel-idiomatic were made as well. This
allows us to easier make packaging changes in the future, and it's more
future-proof if we ever change how inputs (like `ng_module` targets) are
generated (e.g. consider a case where we'd use the `ts_project` rule).
PR Close#43431
We should no longer generate VE shims for workspaces which are not named
`angular`. The default is Ivy compilation and this should be opt-in. The
components repository for example does not need any shims as it is using
Ivy for the common development workflows.
PR Close#43431
Previously, the prodmode output was using ES2015 for `ng_module` and
`ts_library` targets. This commit changes it to `ES2020`. This is
necessary as we want to ship es2020 output in APF v13.
PR Close#43431
In preparation for using the partial compilation transition on the
packager, we need to be able to have a reference to the flat module
out file (that is used as "index" file for entry-point ng_module targets).
We need a reference to the file because with transitions applied, the
inputs are not necessarily in the default `bazel-out` directory. The
packager currently only guesses such paths (this worked most of the
time) but guessing the output directory with transitions will become
impossible.. so the paths need to be computed in a Bazel-idiomatic way.
This is more future-proof and correct (and more clean IMO).
PR Close#43431
Removes the `compilation_mode` attribute for the `ng_module` rule. We
remove the attribute since we intend to control the compilation mode
through the partial compilation build setting we have added before.
Note: We could have named the build setting more generically, something
like `ng_compilation_mode`, but I think it's more readable only assuming
there is `partial` compilation, or `full`. We can always change this in
the future as it is not part of the public API.
PR Close#43431
Previously, `ng_module` generated a second `d.ts` bundle in case the
built target was the Angular core target. This was done so that the
packager later on can ship the `r3_symbols.d.ts` file along with the
APF v13 output. Ngcc relied on this file when it processed the Angular
core package. This is no longer needed for Angular Core v13 since it
will come as partially-compiled without the need for ngcc.
The major benefit of no longer generating multiple dts files here is
that we can reasonably pass the bundle through a provider to the packager
which can then use this for determining the `d.ts` file it should link
in the `package.json`.
This is beneficial and needed for using a transition since the packager
input files are no longer in the default `bazel-out`, so it's important
to keep an reference to the actual Bazel `<File>` instance, allowing
us to determine the path properly in the packager (without any
assumptions on the `bazel-out` path..).
PR Close#43431
We created a build setting (bool flag) for controlling whether partial
compilation should be enabled or not. This commit wires up the build
setting so that all `ng_module` targets respect the flag.
This will later be useful when we apply the transition (which always
sets the partial compilation flag to `True`).
PR Close#43431
Moves the `ng_module.bzl` file into a sub-directory called `ng_module`.
This is consistent with other rules in the package. And it also allows
us to ship the `ng_module.bzl` code next to other tightly-coupled files
like the partial compilation transition/flag.
PR Close#43431
Creates, a currently still unused, Bazel transition that will control
a build setting that is enabling the partial compilation mode for
`ng_module` rule targets. This is in preparation of implementing the
Angular Package Format v13 (which should ship in partial compilation).
Note: Various other approaches aside from the `transition` has been
considered. Here is a small summary of the largest ideas that have
been tried for the APF v13 partial compilation refactor.
**Using an aspect for partial compilation in `ng_package`**
Similar to how we had an aspect for ESM5 compilation in the past,
an aspect could be used to create partial compilation prodmode output
for packaging. The aspect would take the existing prodmode compilation
details and "replay" the compilation with a modified tsconfig that
enables partial compilation.
This _can_ work but requires lots of caution and is very prone to
issues. In order to avoid conflicts with the existing prodmode output,
the partial compilation outputs would need to be written to a
sub-directory. This makes module resolution extremely difficult when
`ng_package` creates the FESM bundles. Also it is difficult to merge
multiple of these aspect-compiled folders into a single one for exposing
the non-bundled ESM output. It becomes especially difficult to ensure
that such an aspect target will actually use the _correct_ dependency
type definition when compiled.
e.g. consider a case where a partial compiled target relies on another
Angular target. The dependency will be compiled partially first, but
the other target _needs_ to rely on the partial compilation `d.ts`
output of the dependency (and *NOT* the devmode `.d.ts` output). This
is incorrect and can cause other type-checking issues / or invalid
output. To make this work, the module resolution when invoking
tsc_wrapped would also need to be updated/patched. This is out of scope
and not reasonable to maintain.
**Exposing a third output flavor directly in the rule**
Instead of replying a compilation, we could expose an output flavor
next to `devmode` and `prodmode`. This sounded like the easiest
solution at first, but it will have the same problems as the aspect
approach (in terms of module resoltion and avoiding conflicts of files).
We cannot control how TS emits `.d.ts` or `.js` files (without patching
into the compiler host), so we would need to store the compilation
output in a sub-folder similar to the aspect.. resulting in the same
issues. This is do-able but would require module resolution to be
patched and we do not have control over `@bazel/typescript`. Also,
`@bazel/typescript` does not forsee a third output flavor, so that
logic would need to be changed significantly as well.
PR Close#43431
Removes the unused `modify_tsconfig.js` file located in the
`@angular/bazel` package. This file existed in the past for the
ESM5 compilation aspect relying on the TS compilation to be replayed.
We just forgot removing the file and associated `nodejs_binary`.
PR Close#43431
