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
The old Sass language referred to as "SASS" here is no longer relevant. This was denoted with the file extension ".sass"
Any new projects should use the modern Sass language which is expressed in ".scss" files.
This change does not remove any support for projects which were already created with ".sass" files, we simply stop offering
this option when creating new projects.
Also correct the capitalization of Less based on how they spell it on their website.
Ivy compatible solution still uses the 'standard' bootstrapping code, however the difference is that there are no factories.
Using a similar approach for `ngc` but without factories and instead of `bootstrapModuleFactory` it uses `bootstrapModule`.
This reverts commit edb84b340ff996df2ca6a2aaf765304cc64fef3e
The team has decided to bring back the faster but potentially less accurate method of detecting lazy routes upon JIT rebuilds (first builds will always use the more complete Angular compiler method). Applications that do not have lazy routes within libraries and that only use direct string literals with loadChildren should not be affected by the potential of less accurate detection. Note that the function overload of loadChildren also does not apply to this situation.
For those projects where correctness of lazy route detection outweighs rebuild speed, please consider using AOT mode for development. AOT mode will also provide a full set of template errors as well which JIT mode is not capable of doing.
Fixes#13102
At the moment when having a default import together with a named import example:
```
import abc, { def } from './foo';
```
And the default import becomes unused it will drop the entire node which will caused used named imports to be dropped as well.
This also adds the option to provide addition files when using `createTypescriptContext` this is paramount for the elide imports tests as without this certain symbols won't have the full details.
Which will cause tests to be false positive and re-surface issues like #13212
When using the `specifier.propertyName` with `typeChecker.getSymbolAtLocation` it will return a more detailed symbol then we originally have in the `usedSymbols` set.
We should probably use `symbol.id` to actually check if the symbols are the same, however the `id` is not exposed in the Symbol interface.
Using `node.name` will return the same symbol that we have stored in the set.
Fixes#13212
* fix(@ngtools/webpack): files are not being updated when using `allowJs` or `resolveJsonModule`
Fixes#13076 and Fixes#12964
* test: add tests for allowJs and resolveJsonModule in watch mode
* test: improve tests for `allowJs`
When not using `allowJs` js files are not processed by the tsc compiler, but still processed by webpack.
So a correct test should be to check that the JS is transpiled down to ES5 syntax.
* build: update `@angular/packages` to `7.1.0`
* feat(@schematics/angular): use tsickle `>=0.34.0` when creating a library
This is the official version that supports 3.1+
* feat(@schematics/angular): use angular version `7.1.0`
* revert: fix(@ngtools/webpack): output consistent filename
This reverts commit df172bdc8af4caa1a908592a8b9400d31c81eeb0.
* refactor(@ngtools/webpack): remove RegExp for ngfactory
This RegExp is not needed as if it actually works it will break lazy loading as in case of AOT, the name should always be suffixed with ngfactory
4c2ce4e8ba/packages/core/src/linker/system_js_ng_module_factory_loader.ts (L83)
At the moment we are processing all property assignments in object literals irrespective if they are in a decorator or not. With this change we will process only property assignments found under in a component decorator.
Fixes#12488, Fixes#6007, Fixes: #6498 and Fixes: #8295
Syntactic errors were only being reported in the type checker when it was running. This caused rebuilds to finish successfully if they had syntactic errors, which could lead to very weird behaviour on rebuilds.
