When a tsconfig without `includes` or `files` all files under the `rootDir` will be included in the compilation. This results in redundant files to inserted as part of the ts compilation which in some cases might reduce the compilation drastically.
Related to: TOOL-949
Webpack and its development server assume the presence of two node builtins (`events` & `querystring`). Do to package hoisting npm/yarn will usually place the shims for those two builtins at locations that webpack find them. This is however not guaranteed nor will it work with pnpm which strictly follows the prescribed dependency tree.
To remedy this, the specific node shims are enabled only for the specific internal webpack files that are used within the development server. This ensures that the requirements of these files does not pollute the entire application.
Fixes#13680
The package is quite large at 33MB (46MB on disk). The package is also only used in one test that is already covered by an E2E test. The E2E test does not require the package to be present for development as the test installs it within a generated project during execution. This also has the benefit of testing the icons package in a more real world use case; as well as allowing the test to serve as a guide for a user to add the package to their own application.
* test: update tests to work with new stricter tsconfig file inclusions
* fix(@schematics/angular): exclusively list the files in tsconfigs
With the omission of `includes` or `files` in tsconfig files tsc will pick up all the files under the rootDir and make them as part of the compilation. In certain cases, redundant files will be picked up which will cause a slower compilations.
Related to: TOOL-949
This change synchronizes the behavior of classic scripts and module scripts (`type="module"`). Module scripts are deferred by default. Also, certain injected scripts are not considered module scripts even in a ES2015+ build due to the strict mode behavior of module scripts. Deferring such scripts also ensures consistent execution in those scenarios.
This allows the output path of an application's index HTML file to be controlled independently of the input file. The output path for the file will be considered relative to the application's configured output path. This allows an application to contain multiple input index files for different configurations and allow the output file to remain constant. This also enables the placement of the index file in a subdirectory within the output path or change the name of the output index file neither of which was previously possible.
Compiler host `readResource` is always called with POSIX seperators. However the `denormalizePath` method doesn't convert forward slashes to back slashes which causes `getModifiedResourceFiles` to return an empty `Set`.
We were also assuming that `_changedFiles` is an FS path which was not the case as it's original type is `Path`
Fix#15012
`ng serve` was errantly adding a module type to custom script bundles. These scripts may contain ES5 and non-strict compatible code and can therefore not be marked as module scripts. `ng build` already correctly operates in this fashion.
Fixes#14952
The lazy option inside the script and style option is confusing as this option doesn't lazy load a bundle but rather it doesn't inject/reference the script in the HTML. While this option is an enabler for lazy loading, the users will still need to handle on how how this bundle will be lazy loaded. There are also potential use cases beyond lazy loading for the option.
Closes#14814
