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
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
At the moment, when the tslint formatted is non human readable, it is being fully silenced.
This changes this behaviour and only emit the formatted result.
Fixes#13173
* 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.
* feat(@schematics/angular): account for root level assets and `resourcesOutputPath`
By default we are only account for assets inside the assets folder. Which breaks the offline experience.
Fixes#13067
* test: add test to verify root level assets in service workers
* feat(@angular/cli): update schema to match new `sourceMap`
* feat(@angular-devkit/build-angular): fine grain settings for sourceMaps
This PR add more control over which sourceMaps you want, Now you can enable sourceMaps for scripts only, styles only or both. Also we added another functionality which are hidden sourcemaps. These are normaly used for error reporting tools.
Fixes#7527
* 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)
This commits adds a base href value in the karma context iframe used to run unit tests.
It solves a very old issue in Angular https://github.com/angular/angular/issues/12295 where a unit test throws:
No base href set. Please provide a value for the APP_BASE_HREF token or add a base element to the document.
even if the application is fine. This is because the `index.html` from Angular CLI contains a base href value, but not the Karma context iframe. So when adding a unit test with a testing module that imports a NgModule, for example `AppModule`, which itself imports `RouterModule`, the unit test used to throw an error (regression appeared in router 3.1).
That could be solved by either adding `RouterTestingModule` to the testing module, or by adding a provider `{ provide: APP_BASE_HREF, useValue: '/' }`, but required to understand the issue (see how many thumbs up there are on the original issue).
This solves the issue in a transparent way: developers won't even encounter the problem anymore.