The TypeScript `emitDecoratorMetadata` option does not support forward references of ES2015 classes due to the TypeScript compiler transforming the metadata into a direct reference of the yet to be defined class. This results in a runtime TDZ error. This is a known limitation of the `emitDecoratorMetadata` option.
The change in the PR removes the need for the option by storing the information in a static property function via the use of the tsickle `ctorParameters` transformation. By leveraging the existing functionality, no changes to the framework code is necessary. Also, minimal new code is required within the CLI, as the relevant tsickle code can be extracted and used with several local modifications.
The bootstrap code always needs to be replaced if not running in JIT mode as other wise the entire compiler will be pulled in because we will not replace the bootstrapping code to use `platform-browser` instead of `platform-browser-dynamic`.
A transformer should not mutate existing nodes, ever. If you intend to modify some part of the node, the ts.update* methods are correct. Or you can replace a node entirely via ts.create* operations, but there are cases where introducing entirely synthetic nodes will break TS output.
Hence using the updateClassDeclaration in this case is the correct approach.
This has also been raised in the slack #ts-core channel as TypeScript have been looking to get to the bottom of this Microsoft/TypeScript#29365 (comment), which seemed to have been caused by mutating the node.
When add module is resolved, it will try to convert the module using the `NGCC` API.
NGCC will be run hooked to the compiler during the module resolution, using the Compiler Host methods 'resolveTypeReferenceDirectives' and 'resolveModuleNames'. It will process a single entry for each module and is based on the first match from the Webpack mainFields.
When Ivy is enabled we also append the '_ivy_ngcc' suffixed properties
to the mainFields so that Webpack resolver will resolve ngcc processed
modules first.
At the moment, since there are no old files in the compilation it will cause all source files to be invalidate after the first run. This shouldn't be done as it will slow down the 2nd recompilation.
This feature ONLY matches the format below:
```
loadChildren: () => import('IMPORT_STRING').then(m => m.EXPORT_NAME)
```
It will not match nor alter variations, for instance:
- not using arrow functions
- not using `m` as the module argument
- using `await` instead of `then`
- using a default export (https://github.com/angular/angular/issues/11402)
The only parts that can change are the ones in caps: IMPORT_STRING and EXPORT_NAME.
At the moment we are leaking devkit paths as `getCurrentDirectory` is used by the ngtsc compiler if no `rootDir` directories is provided.
`getCurrentDirectory` is also used to contruct the `rootDirs` option which is causing this to be incorrect as under Windows as `rootDirs` will be have an invalid value example: `/c/foo/bar`
This PR complements https://github.com/angular/angular/pull/29151
**Note** that this currently works because we are normalizing paths with posix seperators and is mimicking the behaviour of the logical file system used by the ngtsc.
Fixes: #13849
With directTemplateLoading enabled, components
can now use .svg files as templates. For AOT builds,
the Angular compiler host now reads .svg files
directly when reading component templates.
For JIT builds, replaceResources creates a require call
that directly uses raw-loader instead of using the
loader provided by the current webpack configuration.
Closes#10567
* refactor(@ngtools/webpack): support import-based loader resolution
* fix(@angular-devkit/build-angular): ensure correct ngtools loader version
By using the the direct import approach, the loader will be guaranteed to originate from the same package version/location as the other `@ngtools/webpack` imports.
Fixes#13539
The webpack plugin was leaking our internal Path abstraction to the Angular compiler via the `ngProgram.listLazyRoutes` call.
This Path abstraction is provided by `@angular-devkit/core` and shouldn't leak. Instead a TS-like path should be provided to the Angular program.
Fix#13531
