This change aligns with the supported Node.js versions of the Angular CLI.
See: https://github.com/angular/angular-cli/pull/24026
BREAKING CHANGE: Angular no longer supports Node.js versions `14.[15-19].x` and `16.[10-12].x`. Current supported versions of Node.js are `14.20.x`, `16.13.x` and `18.10.x`.
PR Close#47730
Updates the version range in the compiler to require at least TypeScript 4.8. Note that I'm keeping the backwards-compatibility layer for 4.7 around for now until internal projects have been migrated to 4.8.
BREAKING CHANGE:
TypeScript versions older than 4.8 are no longer supported.
PR Close#47690
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
Adds support for TypeScript 4.8 and resolves some issues that came up as a result of the update.
Most of the issues came from some changes in TypeScript where the `decorators` and `modifiers` properties were removed from most node types, and were combined into a single `modifiers` array. Since we need to continue supporting TS 4.6 and 4.7 until v15, I ended up creating a new `ngtsc/ts_compatibility` directory to make it easier to reuse the new backwards-compatible code.
PR Close#47038
Updates the tsickle version in the repository and accounts for its changes in
the `compiler-cli` package. Tsickle made a breaking change in the minor version
segment bump that would break the use with `@angular/compiler-cli`
Additionally the tsickle version for `@angular/bazel` is updated since
we updated `@bazel/typescript` to also account for the breaking changes.
See: 78a0528107
PR Close#47018
`@angular/bazel` currently uses an older version of `@microsoft/api-extractor` which is causing downstream issues in Components. These changes bump up to a version that has a fix.
Context: https://github.com/angular/components/pull/25027
PR Close#46259
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
In v14, the partial compilation output of components have changed in a way
that prevents older versions of Angular to compile the partial declarations
correctly.
In particular, we used to emit used directives/components in separate arrays called
`components` and `directives`, and used pipes in a property called `pipes`:
```js
TestComponent.ɵcmp = i0.ɵɵngDeclareComponent({
minVersion: "12.0.0",
version: "13.3.0",
type: TestComponent,
selector: "ng-component",
ngImport: i0,
template: ``,
isInline: true,
directives: [{ type: i1.SomeDir, selector: "[some-dir]" }],
components: [{ type: i1.SomeCmp, selector: "some-cmp" }],
pipes: { 'async': i2.AsyncPipe },
});
```
In the above example, the `version` property indicates which exact compiler
version was used to compile the component, but the `minVersion` allows older
versions of the compiler/Angular linker to "link" the partial declaration to
its final AOT compilation output.
In v14, the used directives, components and pipes are now emitted together
into a single array under the `dependencies` property:
```js
TestComponent.ɵcmp = i0.ɵɵngDeclareComponent({
minVersion: "12.0.0",
version: "13.3.0",
type: TestComponent,
selector: "ng-component",
ngImport: i0,
template: ``,
isInline: true,
dependencies: [
{ kind: "directive", type: i1.SomeDir, selector: "[some-dir]" },
{ kind: "component", type: i1.SomeCmp, selector: "some-cmp" },
{ kind: "pipe", type: i2.AsyncPipe },
],
});
```
This change has been made in support of standalone components, but it does mean
that older compiler versions can no longer link these partial declarations
as desirable as none of the components, directives and pipes would be included
in the AOT-compiled code.
By increasing the `minVersion` property, we hint to older compiler versions that
they are not capable of processing the partial declaration. This allows reporting
an error at compile time instead of resulting in runtime failures due to missing
components, directives and pipes.
PR Close#45782
Adds support for TypeScript 4.7. Changes include:
* Bumping the TS version as well as some Bazel dependencies to include https://github.com/bazelbuild/rules_nodejs/pull/3420.
* Adding a backwards-compatibility layer for calls to `updateTypeParameterDeclaration`.
* Making `LView` generic in order to make it easier to type the context based on the usage. Currently the context can be 4 different types which coupled with stricter type checking would required a lot of extra casting all over `core`.
* Fixing a bunch of miscellaneous type errors.
* Removing assertions of `ReferenceEntry.isDefinition` in a few of the language service tests. The field isn't returned by TS anymore and we weren't using it for anything.
* Resolving in error in the language service that was caused by TS attempting to parse HTML files when we try to open them. Previous TS was silently setting them as `ScriptKind.Unknown` and ignoring the errors, but now it throws. I've worked around it by setting them as `ScriptKind.JSX`.
PR Close#45749
Adds a little golden test for the new `types_bundle` rule that ensures
the rule works at a general level. This rule will be useful for non-APF
ESM packages like the Angular compiler-cli (for which we also want to
bundle types to make them compatible with TypeScripts ESM type
resolution)
PR Close#45405
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
Updates us to version 4.0 of Jasmine and fixes some errors that were the result of us depending upon deprecated APIs. We need to do this both to stay up to date and because it was going to break eventually, because one of the Bazel packages was logging a deprecation warning that version 4.0 was required.
There were also some cases where the state of `ngDevMode` had started leaking out between tests.
PR Close#45558
Updates us to version 4.0 of Jasmine and fixes some errors that were the result of us depending upon deprecated APIs. We need to do this both to stay up to date and because it was going to break eventually, because one of the Bazel packages was logging a deprecation warning that version 4.0 was required.
There were also some cases where the state of `ngDevMode` had started leaking out between tests.
PR Close#45558
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
Drops support for TypeScript older than 4.6 and removes some workarounds in the compiler.
BREAKING CHANGE:
TypeScript versions older than 4.6 are no longer supported.
PR Close#45394
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
