After updating to a more recent version of rollup, rollup started to
complain because the `TreeParseResult` class is being re-exported
twice in the `index.ts -> public-api.ts -> compiler.ts` entry-point.
Rollup threw errors like:
```
Error: "ParseTreeResult" cannot be exported from
<..>/ml_parser/parser.mjs as it is a re-export that references itself.
```
It seems like Rollup ideally would not throw here, similar to TypeScript
which detects that these exports are the same and just dedupes them, but
it's low-effort fixing this for now and actually is a good opportunity
to make the public API a little more easy understand (when looking at
the `compiler.ts` file).
PR Close#43431
This commit proposes adding myself to the codeowners for `bazel`. I
have made various changes for quite some time to `@angular/bazel` and
with the new APF v13 changes, a lot of code was simplified.
As one of the primary consumers of `@angular/bazel` (in the name of the
Angular components repo), I think it would be reasonable to have an eye
on changes to the Bazel package.
PR Close#43431
As part of APF v13, we ship Angular framework packages using partial
compilation. This is done in preparation of VE removal, and to
eventually get rid of `ngcc` processing.
The new library format allows libraries to switch away from the View
Engine package format without shipping Angular definitions with
instructions to NPM. This would make libraries tightly coupled to
specific versions of `@angular/core`.
Since Angular core is always compatible with itself, we always should
compile Angular core using full compilation mode. It is unreasonable
to ship Angular core with partial compilation output, especially since
we would need to export the linker `declare` functions in
`r3_symbols.ts` otherwise.
PR Close#43431
All other frameworks packages are now using APF v13 and are strict
ESM packages. The compiler-cli does not use APF and is currently shipped
with its devmode ES5 CommonJS sources. This is problematic as CommonJS
cannot simply import from ECMAScript modules (like `@angular/compiler`).
To fix this we use a bundler that allows us to ship the compiler-cli as
a strict ESM package. Note: An ESM can import from an ESM without any
problems. This is what we need hre.
Unfortunatley we need a bundler here because converting the compiler-cli
to ESM is non-trivial as relative imports would need an explicit
`.js` extension. This work can be simplified by using a bundler that
avoids relative imports completely.
Note: This commit uses code-splitting to create multiple bundle
entry-points for `yarn ngc, `yarn ngcc` etc. This commit removed
the old `ivy-ngcc` entry-point that just printed an error message
(to reduce amount of bundles having to be configured).
PR Close#43431
For APF v13, terser has been updated to v5, and the prodmode output
has changed from ES2015 to ES2020. This results in some changes in
the symbol extractor test. Here are the two causes of changes:
* As said in the previous commit, Terser drops the initializer for
variables which are set to `undefined`. We have updated the symbol
extractor to always capture such declarations w/o initializer now.
This means that a couple of declarations that a couple of new
symbols are captured now. These previously didn't have an initializer
even without Terser, and just didn't show up before.
* Terser changed its inline mechanism for functions that recursively
call themselves. Such functions are no longer inlined and therefore
show up in goldens now.
PR Close#43431
Updates the symbol extractor test to work with Terser v5 that
drops the variable declaration initializer if it is explicitly set
to `undefined`. We want to capture such identifiers in the bundles
as otherwise the majority of top-level declarations which are intially
set to `undefined` would be hidden in size goldens.
PR Close#43431
With the changes to support APF v13 in the `ng_package` rule, we have
removed the ambiguous `entry_point` attribute. The attribute suggested
that it would be used for determining the primary entry-point input
file. This was not the case as the flat module output file is consulted
for bundling et at. The attribute has been renamed to match its
purposed (renamed to `primary_bundle_name`).
We no longer need to set that attribute because the primary bundle
name is (1) not of relevance for consumers and (2) the rule already
infers the bundle name properly from the Bazel package.
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
Updates the primary tsconfig files to use ES2020 as target and module.
This helps IDEs and reflects what we generate in production, allowing
the use of JS features that are natively supported in APF v13.
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
Updates the Bazel setup to the latest shared dev-infra package. Also the
rules_nodejs version is updated to v4.2.0. We have landed various
changes that prepare us for the APF v13 implementation. e.g.
* Ability to control the linker mappings for the `ng_package` rule. This
will become important for using a transition that could accidentally
cause linker mappings that would otheriwse conflict.
* Use of latest version of rollup & terser in the Bazel rules the
dev-infra package exposes. This is necessary for ES2020 support.
PR Close#43431
In 3.6.0 jasmine added a required `pp` parameter to the `jasmineToString()` function
signature. This commit updates our own use of this signature to ensure that compilation
succeeds with the latest jasmine typings.
PR Close#43411
This commit removes the `WrappedValue` public API from `@angular/core`
which was deprecated in Angular 10 without replacement.
BREAKING CHANGE:
The `WrappedValue` class can no longer be imported from `@angular/core`,
which may result in compile errors or failures at runtime if outdated
libraries are used that are still using `WrappedValue`. The usage of
`WrappedValue` should be removed as no replacement is available.
PR Close#43507
This commit fixes an oversight in the JIT compilation of partial factory
declarations, where the literal `'invalid'` was not accounted for
(unlike the AOT linker).
Fixes#43609
PR Close#43619
add a button type in the example of creating a dynamic form so that the button that adds the alias control does not submit the entire form
PR Close#43666
fix the keyword "browser" present in code segments being incorrectly
generated as a link to "api/animations/browser" by applying the
no-auto-link class
PR Close#43554
This reverts commit ab3de40ba3, which is
itself a revert of the original commit. Thus, this restores the changes
to schematics in support of ESM.
Now that g3 has a local modification for load_esm, we can restore this
functionality.
PR Close#43637
Now that `Route.loadChildren` no longer accepts a string, there is no
need for tooling to find all string-based `loadChildren` to setup lazy
imports for them. As a result, the `listLazyRoutes` operation that
enumerates all string-based `loadChildren` occurrences is no longer
needed and is therefore removed from the compiler.
The `listLazyRoutes` API remains on the `Program` interface to avoid
breaking external tools that may be using this method, but those tools
should ultimately move away from using this API.
PR Close#43591
This commit removes the ability to configure lazy routes using a string
for `loadChildren`, together with the supporting classes to load an
`NgModuleFactory` at runtime.
BREAKING CHANGE:
It is no longer possible to use `Route.loadChildren` using a string
value. The following supporting classes were removed from
`@angular/core`:
- `NgModuleFactoryLoader`
- `SystemJsNgModuleFactoryLoader`
The `@angular/router` package no longer exports these symbols:
- `SpyNgModuleFactoryLoader`
- `DeprecatedLoadChildren`
The signature of the `setupTestingRouter` function from
`@angular/core/testing` has been changed to drop its `NgModuleFactoryLoader`
parameter, as an argument for that parameter can no longer be created.
PR Close#43591
With Ivy it's possible to create a `ComponentFactory` instance based on the generated Component def, thus the `ViewContainerRef.createComponent` can accept a Component instance and create a factory inside, rather than requiring additional complexity of creating a ComponentFactory outside (by invoking `ComponentFactoryResolver`).
This should simplify the API that is used for creating components dynamically.
DEPRECATION:
Angular no longer requires component factories to dynamically create components. The factory-based signature of the `ViewContainerRef.createComponent` function is deprecated in favor of a different signature that allows passing component classes instead.
PR Close#43022
Many of the tests in the router code use the deprecated loadChildren as a string. This
has been deprecated for years and can easily be changed to just a function that
returns the module.
PR Close#43578
In the API docs, concrete classes do not list the "implementation" overload on a method, since this is not strictly part of its API.
There is already a special case for abstract methods that do not have such an implementation overload.
But we were missing the case where the method was part of an interface. In interfaces none of the methods have implementation overloads.
Fixes#43001
PR Close#43614
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
DEPRECATION:
In Ivy, AOT summary files are unused. Passing AOT summary files in TestBed has no effect, so the `aotSummaries` usage in TestBed is deprecated and will be removed in a future version of Angular.
PR Close#43395
Currently, migrations and schematics must be in CommonJS format. However, framework packages will only be ESM from v13 and onward. To support this configuration, dynamic import expressions are now used to load `@angular/compiler`. Dynamic imports within Node.js allow the `@angular/core` migrations’ CommonJS code to load ESM code. Unfortunately, TypeScript will currently, unconditionally down-level dynamic import into a require call. `require` calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import. Due to the use of the dynamic import, a reference to the compiler module must now be passed to all locations that use values from the `@angular/compiler` package.
PR Close#43627
A base class that can be used to implement a Render3 Template AST visitor is now used throughout the `@angular/core` migrations. This class is used instead of the `NullVisitor` found within the `@angular/compiler` because the `NullVisitor` requires a deep import which is no longer supported with the ESM bundled packages as of v13. The `NullVisitor` is also fairly trivial in regards to its implementation and the new base class also provides additional helper methods for migration specific behavior. This removes all remaining deep imports of the `@angular/compiler` package from the `@angular/core` migrations while avoiding the need to modify the `@angular/compiler` package.
PR Close#43627
Paul Gschwendtner