NgModule factories are obsolete with Ivy and most of the operations can already be performed with NgModule classes without retreieving corresponding factories. NgModule factories were useful to generate an `NgModuleRef` (via `NgModuleFactory.create` method). This commit adds a new function to create an instance of the `NgModuleRef` class without having the need to create a factory first.
PR Close#43580
This commit adds a new function called `getNgModuleById` to the public API surface of the framework. The `getNgModuleById` function allows to retrieve loaded NgModule class by id (specified via `@NgModule.id`). The function is a replacement for the `getModuleFactory` function.
DEPRECATION:
The `getModuleFactory` function is deprecated in favor of the `getNgModuleById` one. With Ivy it's possible to work with NgModule classes directly, without retrieving corresponding factories, so the `getNgModuleById` should be used instead.
PR Close#43580
When compiling your application using the AOT compiler, your templates
are type-checked according to a certain strictness level. Before Angular 9
there existed only two strictness levels of template type checking as
determined by [the `fullTemplateTypeCheck` compiler option](guide/angular-compiler-options).
In version 9 the `strictTemplates` family of compiler options has been
introduced as a more fine-grained approach to configuring how strict your
templates are being type-checked.
The `fullTemplateTypeCheck` flag is being deprecated in favor of the new
`strictTemplates` option and its related compiler options. Projects that
currently have `fullTemplateTypeCheck: true` configured can migrate to
the following set of compiler options to achieve the same level of
type-checking.
```json
{
"angularCompilerOptions": {
"strictTemplates": true,
"strictInputTypes": false,
"strictNullInputTypes": false,
"strictAttributeTypes": false,
"strictOutputEventTypes": false,
"strictDomEventTypes": false,
"strictDomLocalRefTypes": false,
"strictSafeNavigationTypes": false,
"strictContextGenerics": false,
}
}
```
PR Close#43224
The `skipTemplateCodegen`, `strictMetadataEmit` and
`enableResourceInlining` options are specific to ViewEngine and have no
effect when using the Ivy compiler. Since libraries can no longer be
compiled using ViewEngine from Angular 13, this commit removes these
options entirely.
The `annotateForClosureCompiler` is also no longer recommended to use,
as Closure Compiler is not supported outside of Bazel.
Finally, the `fullTemplateTypeCheck` flag is changed into
`strictTemplates` as the former flag is being deprecated. Enabling
`strictTemplates` does result in more strict type-checking than with
only `fullTemplateTypeCheck` enabled, but simply removing
`fullTemplateTypeCheck` right away would result in less strict
type-checking which is not desired.
PR Close#43224
when some auto code links fail to happen they can be added manually
with the md ``[`code text`](link)``, these generate anchor elements which
contain a code element, such code element does not get the correct text
color, this commit fixes such issue
PR Close#43586
remove the deprecated tslint from the examples of type cli
note: eslint hasn't be applied and linting has been removed entirely
to follow angular's unopinionated view on linting
PR Close#43592
Update the AIO scripts that use Lighthouse (i.e. `audit-web-app.js` and
`test-aio-a11y.js`) to ES modules. This allows consuming
`lighthouse/lighthouse-cli` [v8.5.0+][1], which also switched to ES
modules.
NOTE:
Switching the `test-aio-a11y.js` script to ES modules is not strictly
necessary, since it invokes `audit-web-app.mjs` via a shell command, but
it was done for consistency.
[1]: https://github.com/GoogleChrome/lighthouse/releases/tag/v8.5.0
PR Close#43607
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
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-cli` and its new secondary entry point `@angular/compiler-cli/private/migrations`. 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 dynamically loaded modules must now be passed to all locations that use values from the modules.
PR Close#43657
The Router code currently has special-case handling around when and how
the internal state is reset. Specifically, it only resets the internal
tracking of the state when an error is thrown, which does not happen
when guards reject or resolvers return `EMPTY`. Other than the
navigation URL not matching a config, guards rejecting would be the main
cause of a navigation being turned down.
This change updates the router code to always reset the internal state
in the same way, regardless of the reason for navigation cancellation.
In the end, this will only affect _very_ specific use-cases with
`UrlHandlingStrategy`. Because the internal state is not updated until
the end of the transition pipe, the state reset generally doesn't do
anything at all. However, because the `rawUrlTree` is reset by calling
`urlHandlingStrategy.merge` with the _attempted_ `rawUrl` that failed,
the resulting browser URL reset could be different than before (but will
now be consistent with how the URL is reset in other scenarios, like a
URL not matching a `Route` config).
PR Close#43651
Internally, g3 code still uses the `loadChildren: string` syntax. We
need to continue to provide this functionality with an internal patch.
This change makes that patch easier by only touching stub files that
support the `loadChildren: string` (other than `router_config_loader`).
PR Close#43660
DEPRECATION:
The template prefixes `bind-`, `on-`, `bindon-`, and `ref-` have been deprecated
in v13. Templates should use the more widely documented syntaxes for binding and references:
* `[input]="value"` instead of `bind-input="value"`
* `[@trigger]="value"` instead of `bind-animate-trigger="value"`
* `(click)="onClick()"` instead of `on-click="onClick()"`
* `[(ngModel)]="value"` instead of `bindon-ngModel="value"`
* `#templateRef` instead of `ref-templateRef`
PR Close#43671
Updates the size goldens for the integration CLI tests to
reflect the new payload with APF v13 and the CLI v13-next.7
Overall, there seems to be some increase in the polyfills
and a ~400b increase for the `main` bundles. This seems to
because with APF v13, the core package no longer uses the
downleveled `Object.assign`, but the spread operator directly.
ESbuild will then downlevel the spread to `__spreadProps` which
seems to come with more transitively-required helpers that
end up contributing to the ~400b increase. The spread is downleveled
even for the modern browsers this integration test targets, because
it is a trick to wrokaround a performance bug in V8. So the size
increase is reasonable given the runtime improvement. More details
here:
https://github.com/evanw/esbuild/issues/951#issuecomment-796972298.
PR Close#43431
Updates the size goldens for the two AIO production build jobs.
Due to the removal of differential loading, the bundle names no
longer include the ES version being used, so we remove that suffix.
The styles overall decreased. Additionally, the main bundle became
noticable smaller, with a little increase in the polyfills. The AIO
job not using APF v13 seems larger but this is likely due to the current
Angular v13 packages (in the `test_aio`) job still using View Engine
APF v12 with the CLI v13 (where some optimizations might not match up anymore).
PR Close#43431
This commits sets the JS target for all command line tools to
NodeJS v12. ESbuild will automatically downlevel the ES2020 features
we currently use to make them compatible with NodeJS v12 <-> ES2019.
ES2020 is the prodmode output, but we still support Node v12 so
there needs to be some downleveling for now.
Note: This is a separate commit because initially the target was
set to Node v14 to match up with the prodmode Bazel output.
PR Close#43431
Simplifies the `last_segment_name` computation in the integration
test Starlark macro we use. The last segment name could be computed
in a shorter way and this has come up while being at it (through review;
so this commit addresses that).
PR Close#43431
Similar to the other private entry-points we have added for localize,
bazel or the migrations, we should expose the tooling code through
a dedicated private export. This will make the compiler-cli exports
more consistent and it will become easier for the CLI to export
necessary code.
PR Close#43431
Currently, some tests in the `compiler-cli/integrationtest` package fail
on Windows because there are spec files which are not Bazel-generated.
When Bazel runs these tests on Windows, the spec file is resolved to
the actual source file (since there is no runfile symlinking/sandboxing).
This breaks the execution of the CJS spec file since it resides in th
`packages/compiler-cli` source folder which has a `package.json` set to
`type: module`.
We fix this by adding a `package.json` file for the integration test
folder and setting `module` to `commonjs`.
PR Close#43431
The package builder script should respect the `BAZEL` environment
variable for running Bazel. If not set, it can fallback to bazelisk
from the `node_modules`. Respecting this variable allows for users
with a global `bazel` binary. This is desirable in some situations,
like on Windows, where running Bazel inside of the Yarn environment
seems slower than running a global variant. This could appear like that
because projects might use different Bazel versions. In some cases,
developers would want to use a single (already-warmed-up) instance of
Bazel instead of launching different versions using bazelisk.
(e.g. when switching a lot between repos like COMP, FW or CLI..)
In any case, it doesn't hurt providing this flexibility for advanced
use-cases. It's low-effort to maintain and is respected in COMP as well.
PR Close#43431
Temporarily disables the Bazel integration test as it will not
work with the APF v13 output which is strict ESM. We need to
land some logic in `rules_nodejs` first that would allow an
ESM variant of `@angular/compiler-cli` to work.
Once this happened and there is a new release, we can re-enable
the test and make adjustments for v13 APF (i.e. running the linker
plugin when creating the rollup bundles).
PR Close#43431
This commit temporarily disables the SystemJS upgrade e2e tests. All of
the upgrade e2e tests (except for `phonecat-1-typescript`) rely on UMD
bundles. These are no longer available for the v13 Angular package
output, so we disable the tests for now.
These e2e tests can be re-enabled once we migrated the exampels from
UMD bundles to e.g. the CLI, or some custom rollup build. Alternatively
it might be even possible to use FESM bundles directly (depending on
browser support for the AIO examples; this is something the docs-infra
team will have to determine though).
PR Close#43431
With the APF v13 package output, deep files can no longer be imported.
Since we do not intend to bundle the compiler into the compiler-cli, we
need to switch all deep imports to the primary entry-point.
PR Close#43431
We updated the dev-infra version as part of the v13 package format
in order to be able to use the latest `rollup` version (and its
plugins). The update of the shared dev-infra package resulted in an
update of Chromium to a more recent version. This version of Chromium
seems to normalize the `content-type` header differently, so that the
AIO `http` example test assertion needs to be updated to work with the
new version of chromium. This commits updates the test.
PR Close#43431
Adding suites to the `IGNORED_EXAMPLES` array currently results
in an runtime exception because later when ignored examples are
printed to stdout, a non-existent variable is referenced back
from when there were examples disabled due to the Ivy migration.
This commit fixes the logic.
PR Close#43431
Updates the `hello_world_closure` integration test to use APF v13
in combination with the linker plugin which is needed as running
the `ngc` command standalone does not modify the `node_modules`
and the FW packages remain partially compiled. A step in between
using rollup can create a linker-processed bundle of all FW
packages.
PR Close#43431
Updates the dynamic-compiler test to be compatible with the APF v13.
As of v13, the packages no longer come with metadata.json files and
now need to be processed with the babel linker plugin. This commit
sets up the linker plugin, and switches away from the deprecated
systemjs approach to a simpler rollup code-splitting variant.
PR Close#43431
Invalidate the cache for node modules so that the CLI builds from
the snapshot repositories are used. Due to a bug in Yarn, and the need
of using the `github:<..>` syntax, the old artifacts from previous runs
are incorrectly cached. This could have been prevented by using an actual
full Git ref URL, but unfortunately that does not work because the CLI
devkit snapshot dependencies set snapshot builds as deps as well. The URLs
here need to match as otherwise Yarn will conflict. e.g.
```
Pattern ["@angular-devkit/core@github:angular/angular-devkit-core-builds#64b7e2b1d"] is trying to unpack in the same destination "/Users/paul/Library/Caches/Yarn/v6/npm-@angular-devkit-core-13.0.0-next.6/node_modules/@angular-devkit/core" as pattern ["@angular-devkit/core@github:angular/angular-devkit-core-builds#0e7277c63"]. This could result in non-deterministic behavior, skipping.
```
PR Close#43431
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
Ngcc relies on cluster for distributing work. The master controller
sends messages to the workers as soon as the worker becomes `online`.
The online event is sent as part of the NodeJS cluster logic itself.
This does not work well because technically `online` could emit before the
worker started listening (this seems to be case now with ESM as the
imports are loaded in a way where `online` emits too early; before the
worker actually listens for messages).
We fix this by explicitly notifying the master when the worker
is ready for retrieving IPC messages/or tasks. This is more safe
anyway as it's not clearly specified when `online` emits.
PR Close#43431
Given that we ship all of compiler-cli and localize in ESM
mode now, we need to use a ESM compatible version of Yargs.
The latest version seems ESM compatible but with some small
API changes. This commit updates Yargs and updates the command
line option code to use the new API.
PR Close#43431
Updates the lock file resolution logic in ngcc to work with ESM output.
The compiler-cli is now shipped in bundles, so the actual module resolution
needs to stay to keep the lock file path consistent regardless of where the
lock file code is bundled into. The ngcc integration test needs to be updated
though since the `ngcc` entry-point will always reside in the `bundles/` directory
now.
It has been considered using the top-level `package.json` of the compiler-cli
package, but that caused problems in tests down the line because the ngcc
tests only have the `@angular/compiler-cli/ngcc/...` targets linked into
the node modules. It's not worth changing this and reworking tests if ngcc
is going away in the future anyway (+ it has been like that before!).
PR Close#43431
Switches the compiler-cli usage of `__filename` to `import.meta.url`
when ESM bundles are generated. Unfortunately we cannot start using
only `import.meta` yet as we still build and run all code in Angular
in CommonJS module output for devmode tests.
This commit also fixes various instances where a jasmine spy was applied on
a namespace export that will break with ES module (and the interop for
CommonJS output). We fix these spies by using a default import.
PR Close#43431
Removes the remaining usages of dynamic require statements in the
package output. Since we declare all shipped packages as strict ESM,
we cannot use dynamic require statements anymore. This commit switches
these usages to actual `import` statements.
Note: Tsickle continues to remain an optional dependency since bundling
does not work with its UMD package output. Also tsickle is rarely used by
consumers, if at all, so bundling does not really provide any significant
value. To continue keeping tsickle optional (since it's still needed by the
`annotateForClosureCompiler` option which is also respected in ngtsc), we
pass-through a tsickle instance as a parameter to `main`. This allows us to
keep the compile functions synchronous without having to refactor the majority
of the watch compilation code, and majority of tests for ngc, ngtsc.
Consumers (like the `ngc` bin entry-point) can then load tsickle based on their
module format. e.g. tsickle can be imported through `require` to keep everything
sync, but in ESM, the dynamic import can be used beforehand to pass `tsickle` to
the `main` function. We can revisit this in the future but for now this does the
trick without exceeding the scope of this commit..
PR Close#43431
As of v13, the package output will be using partial compilation output.
This breaks the Bazel setup similar to how it breaks Angular Components.
The problem is that `@bazel/concatjs` relies heavily on the UMD files
that previously existed in APF, plus it assumed that ngcc pre-processed
the files in the `node_modules`. This is no longer the case as there are
no UMD files, and the code is not fully-compiled by the Angular
compiler.
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
This wires up the `@angular/localize/tools` entry-point. For context:
This entry-point is being created to avoid deep imports into
`@angular/localize/src/tools/<..>` like the CLI relies on. Deep imports
do not play well with strict ESM, and now that all APF packages are
strict ESM, the tool code needs to be either strict ESM as well.
We use ESBuild to create individual bundles for the CLI entry-points,
and the actual tool entry-point. We use a bundler because this enables
the localize code be ESM compatible. Without a bundler, all relative imports
within the `tools` entry-point would need to explicitly have the `.js`
extension. This would be cumbersome and hard to maintain/enforce or
validate.
One might wonder why this is not a standard APF entry-point then. The
answer is that the APF entry-points do not support exposing the CLI
binaries (like `yarn localize-translate`). This could be done through
tertiary entry-points, but using ESBuild directly gives us more control
for now. We might want to revisit this in the future again.
PR Close#43431
Moves the `src/tools` folder of the `@angular/localize` package into the
top-level of the package. This is in preparation of actually exposing an
entry-point for the tools that can be accessed using
`@angular/localize/tools`.
We want to expose such an entry-point because the CLI currently
deep-imports into various places of the tools, but this will not
work well with strict ESM because the localize tool depends on the
v13 strict ESM packages like the `@angular/compiler` or
`@angular/compiler-cli`.
PR Close#43431
