Contains fixes related to the symlink behaviour inside of bazel. Without it, webpack needs to be configured to be aware of symlinks and preserve the paths.
When Ivy is enabled in an app, the app's dependencies are processed by
ngcc (the Angular compatibility compiler), which will generate new
Ivy-compatible entry-points in each package. To allow webpack find those
entry-points, it will add references to them in `package.json`, named
after the original property with the `_ivy_ngcc` suffix. So, for
example, `es2015` and `module` will become `es2015_ivy_ngcc` and
`module_ivy_ngcc`.
Previously, the `mainFields` passed to webpack would give higher
priority to an Ivy entry-point compared to the corresponding non-ivy
entry-point but not compared to other entry-points. For example,
`es2015, module` would becode
`es2015_ivy_ngcc, es2015, module_ivy_ngcc, module`. This could mean that
`es2015` would be preferred over `module_ivy_ngcc`, even though the
former is probably not Ivy-ready. Generally, if `es2015` exists and has
a higher priority than `module`, then `es2015_ivy_ngcc` would be
generated before (or instead of) `module_ivy_ngcc`, but this can be
changed using an ngcc configuration file (`ngcc.config.js`).
This commit fixes this by ensuring that any `_ivy_ngcc` entry-point is
considered before any of the original entry-points in the `mainFields`
list.
NOTE:
While it is possible that a format is Ivy-compatible without bhaving an
`_ivy_ngcc` suffix (e.g. if the user does a manual ngcc pass without
`--create-ivy-entry-points`), it is quite unlikely to happen and even if
it does, choosing a different format should be OK.
Without this change, module names will be computed with incorrect paths containing duplicate path fragments (e.g. `@angular-devkit/architect/testing/testing/test-logger`).
Under Bazel some dependencies might be readonly we shouldn't run NGCC async version because we are unable to verify which modules are read-only and which not.
When in JIT mode during lazy route discovery, the Ivy compiler willl attempt to parse templates which may fail when this plugin is used with webpack loaders that support custom template formats. The string lazy routes must be discovered before the webpack build starts but the template loading/processing does not occur until the webpack build commences.
Fixes: #17002
Running the `remove-ivy-jit-support-calls` and `remove_decorators` transformers causes the following TS bug https://github.com/microsoft/TypeScript/issues/17552 which is why the `elide-imports` transformer exists in the first place.
However, when having a syntax like the below;
```ts
import { AccountComponentChild } from '../@types';
export class SignUpComponent implements AccountComponentChild{}
```
The `implements` parts of the class is called a `HeritageClause` with child statements of `ExpressionWithTypeArguments` also the same is for `abstract`. With this change we check the token of the `HeritageClause` and if it's an `ImplementsKeyword` we elide the import.
Closes#16907
We now add non node_modules `.d.ts` as a dependency of the main chunk. This is important under Ivy, because NG metadata is now part of the declarations files ex:
```ts
export declare class FooComponent implements OnInit {
constructor();
ngOnInit(): void;
static ɵfac: i0.ɵɵFactoryDef<FooComponent>;
static ɵcmp: i0.ɵɵComponentDefWithMeta<FooComponent, "lib-foo", never, {}, {}, never>;
}
```
Previously such files were not being added as dependency and such files didn't get invalidated when changed.
Closes#16920 and closes#16921
This change allows the import eliding capabilities of the plugin to more completely remove the effects of the `setClassMetadata` and `setNgModuleScope` functions. This provides equivalent behavior to the Decorator removal functionality for ViewEngine.
