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
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
Adds support for TypeScript 4.5. Includes the following changes:
* Bumping the package versions.
* Fixing a few calls to `createExportSpecifier` and `createImportSpecifier` that require an extra parameter.
* Adding some missing methods to the TS compiler hosts.
* Fixing an issue in the TS mocks for the ngcc tests where a regex was too agressive and was trying to match a path like `/node_modules/@typescript/lib-es5`.
* Accounting for type-only import specifiers when reporting DI errors (see #43620).
Fixes#43620.
PR Close#44164
This commit updates the `node` engines range for all Angular
framework packages to:
* No longer support NodeJS v12 `< 12.20`. This is done because APF v13
uses package export patterns which are only supported as of v12.20.
https://nodejs.org/api/packages.html#packages_subpath_patterns.
* Allows for the latest v16 NodeJS versions. This matches with the CLI
which added NodeJS v16 support with https://github.com/angular/angular-cli/pull/21854.
We already limit this to `>= v16.10.0` in preparation to only
supporting the LTS minors of Node v16.
BREAKING CHANGE: NodeJS versions older than `v12.20.0` are no longer
supported due to the Angular packages using the NodeJS package exports
feature with subpath patterns.
PR Close#43740
Bumps the minimum required TypeScript version to 4.4.2 and removes the integration tests for 4.1, 4.2 and 4.3.
BREAKING CHANGE:
TypeScript versions older than 4.4.2 are no longer supported.
PR Close#43642
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
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
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
Adds support for TypeScript 4.4. High-level overview of the changes made in this PR:
* Bumps the various packages to `typescript@4.4.2` and `tslib@2.3.0`.
* The `useUnknownInCatchVariables` compiler option has been disabled so that we don't have to cast error objects explicitly everywhere.
* TS now passes in a third argument to the `__spreadArray` call inside child class constructors. I had to update a couple of places in the runtime and ngcc to be able to pick up the calls correctly.
* TS now generates code like `(0, foo)(arg1, arg2)` for imported function calls. I had to update a few of our tests to account for it. See https://github.com/microsoft/TypeScript/pull/44624.
* Our `ngtsc` test setup calls the private `matchFiles` function from TS. I had to update our usage, because a new parameter was added.
* There was one place where we were setting the readonly `hasTrailingComma` property. I updated the usage to pass in the value when constructing the object instead.
* Some browser types were updated which meant that I had to resolve some trivial type errors.
* The downlevel decorators tranform was running into an issue where the Closure synthetic comments were being emitted twice. I've worked around it by recreating the class declaration node instead of cloning it.
PR Close#43281
Updates the api-extractor dependencies of the repository, and within
the `@angular/bazel` package so that TypeScript 4.3 is supported when
a flattened typings file is generated. Without this update, the api
extractor could fail if a referenced tsconfig use a TS 4.3-only option such as
`noImplicitOverride`.
Note: This could also be considered a `feat:` for `@angular/bazel`,
but this package is not part of the public API anyway and we'd want
that change to land in the patch branches too (to keep the goldens
in sync between release branches as much as possible)
PR Close#42737
Switches the repository to TypeScript 4.3 and the latest
version of tslib. This involves updating the peer dependency
ranges on `typescript` for the compiler CLI and for the Bazel
package. Tests for new TypeScript features have been added to
ensure compatibility with Angular's ngtsc compiler.
PR Close#42022
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Remove publishConfig property from the package.json entry for each of the entries in
the publish configuration. Using the wombat proxy is now ensured/managed by the
ng-dev release tooling.
PR Close#42104
With this change we add renovate to update dependencies in the following locations
- WORKSPACE
- integration/bazel/WORKSPACE
- package.json
- packages/**/package.json
- tools/ts-api-guardian/package.json
- aio/package.json
We also enable yarn workspaces so that dependencies in these packages are hoisting to the root and renovate doesn't created nested lock files.
Enabling auto updates is important, because quite often dependencies get out of date especially in the compiler-cli which depends on a number of external dependencies.
PR Close#41407
Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well
as breaking changes.
Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0
Features of note for angular/angular:
* stdout/stderr/exit code capture; this could be potentially be useful
* TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too
heavy weight
Breaking changes of note for angular/angular:
* loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl`
(which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl`
* with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is
no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing
a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm.
* @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that
require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from
`@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old
load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from
`@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library
internals for ng_module.
* runfiles.resolve will now throw instead of returning undefined to match behavior of node require
Other changes in angular/angular:
* integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true.
The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is
supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users
that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with
use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way
as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an
example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin:
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect.
NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel
also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in
angular repo.
* JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions.
PR Close#39182
Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well
as breaking changes.
Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0
Features of note for angular/angular:
* stdout/stderr/exit code capture; this could be potentially be useful
* TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too
heavy weight
Breaking changes of note for angular/angular:
* loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl`
(which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl`
* with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is
no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing
a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm.
* @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that
require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from
`@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old
load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from
`@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library
internals for ng_module.
* runfiles.resolve will now throw instead of returning undefined to match behavior of node require
Other changes in angular/angular:
* integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true.
The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is
supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users
that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with
use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way
as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an
example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin:
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect.
NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel
also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in
angular repo.
* JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions.
@josephperrott, this touches `packages/bazel/src/external.bzl` which will make the sync to g3 non-trivial.
PR Close#37727
Due to an outage with the proxy we rely on for publishing, we need
to temporarily directly publish to NPM using our own angular
credentials again.
PR Close#37378
With this change we drop support for TypeScript 3.8 and remove all related tests.
BREAKING CHANGE:
TypeScript 3.8 is no longer supported, please update to TypeScript 3.9.
PR Close#37129
Remove TypeScript 3.6 and 3.7 support from Angular along with tests that
ensure those TS versions work.
BREAKING CHANGE: typescript 3.6 and 3.7 are no longer supported, please
update to typescript 3.8
PR Close#36329
95c729f5d1 added support for TypeScript v3.8. Since
these versions are now supported, the `typescript` peer dependency
range in `@angular/bazel` needs to be updated to not report unsatisfied
peer dependencies.
PR Close#36013
