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 year has advanced by one cycle. In accordance with this
practice, we increment the value of the bounding set of our
license year by one.
PR Close#44590
As mentioned in the previous commit, integration tests will be declared
in subpackages of `//integration`. For these tests to still rely on the
NPM packages from `HEAD`, we need to update the visibility.
PR Close#44238
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
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 removes special functions that were used to run tests in ViewEngine or Ivy only.
Since ViewEngine is deprecated and we no longer run ViewEngine tests on CI, we can cleanup
those special helpers and ViewEngine-only tests.
PR Close#44120
This commit removes most tests that were designated as only covering View
Engine code. It also removes tag filters from CI and local commands to run
tests.
In a few cases (such as with the packages/compiler tests), this tag was
improperly applied, and certain test cases have been added back running in
Ivy mode.
This commit also empties `@angular/compiler/testing` as it is no longer
necessary (this is safe since compiler packages are not public API). It can
be deleted in the future.
PR Close#43884
Remove the ivy-aot bazel tag from usage as it served a duplicate purpose as ivy-only which is now removed as both are
unneeded with Ivy as the default compiler used.
PR Close#43862
Using the tag "view-engine-only" better describes the expected usage of bazel targets with the test. They can
only be run with view engine.
PR Close#43862
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
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
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
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
The `@angular/core` migrations are currently published as CommonJS and also not bundled. Schematics, of which migrations are a type, are currently required to be CommonJS modules due to the Schematics Runtime not yet supporting ESM-based schematics. To ensure that the migration files are loaded as CommonJS modules, a nested `package.json` file has been introduced within the `schematics` directory of the package to set the `type` field for all containing JavaScript files as CommonJS. Since the migrations are also not currently bundled and the `devmode` output used to build the migrations will replace all relative imports with fully-qualified module specifiers, an additional `exports` entry must be added to allow the fully-qualified module specifiers to correctly resolve. If `devmode` did not change the relative imports the additional entry would not be needed. Bundling would also remedy the situation and is the long-term path, especially once the migrations are converted to ESM. Additional followup changes should investigate bundling each migration. The additional `exports` entry should be removed if either `devmode` behavior is changed or the migrations are bundled.
PR Close#43657
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
As part of v13, all APF packages use the `exports` field which defines
the public entry-points/mappings for a package. so-called package exports.
The `ng_package` rule creates all the necessary mappings/sub-path exports
for the entry-points of `@angular/common`. Though, since the locale files are
generated separately and are not an actual entry-point, we need to expose these
files publicly so that they can be imported/resolved by consumers.
PR Close#43431
Similar to other code that is shipped as part of `@angular/common`
(with APF v13), we should ship the generated locale files as ESM
files as well. This is necessary/reasonable because we explicitly
set `type: "module"` for the common package, so it makes sense to
have the same apply for the locale sub-directory.
Note: The global locale scripts remain having the `.js` extension
and will continue to be unmodified. They are CJS/ESM compatible either
way, but refer to browser globals.
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
Updates the API extractor tool used by the `ng_module` rule to only
accept a single entry-point file. This change is made in preparation
for APF v13 where this logic is no longer needed.
The logic previously only existed to also bundle the `r3_symbols` file.
This file is no longer needed in APF v13 because Angular core no longer needs
to be processed with `ngcc`. This allows us to clean up this logic which
helps simplifying `ng_module`.
Consumers that use an older version of `@angular/core` should
respectively also use a compiler-cli version matching the core
version.
PR Close#43431
Refs #42966.
Previously if _any_ diagnostics were emitted, regardless of their category, the manifest would not be generated. This means that if a target emits only warnings and no errors, it would still fail to build because it does not generate all the required output files (specifically the `.es5.MF` file). Now the manifest file is generated as long as there are no error diagnostics in the result. This makes `ng_module()` support compiler warnings as a user would expect.
Added a test which uses extended template diagnostics to trigger the invalid banana in box diagnostic. This generates a warning and uses Skylib's `build_test()` to verify that it builds successfully. Unfortunately there is no easy way to verify that the warning diagnostic is emitted at all. `expected_diagnostics` should be able to do that, but it doesn't seem to have any effect on `ng_module()` and may not be integrated. Instead, testing that a target with warnings builds correctly is the best we can easily do here without a deeper investigation.
PR Close#43582
Refs #42966.
Fixes#33452.
This allows `ng_module()` targets to be built with strict templates enabled, it mostly works the way we already do this internally. Also adds extended template diagnostics behind an experimental option so it can be used internally and for tests.
`strict_templates` can only be used if `type_check` is also enabled and `experimental_extended_template_diagnostics` can only be used if `strict_templates` is enabled.
PR Close#43582
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
