By default, a glob pattern starting with a forward slash will be "mounted" onto the system root. This causes globs to escape the workspace root.
With this change we configure disable glob "mounting" and also change the root to the same setting of the `cwd`.
Closes#23467
When using localization we setup `SIGINT` signal to delete the temporary directory. In some cases this resulted in delaying the process from exiting a couple of seconds.
Closes#22216
Prepares the `@angular-devkit/build-angular` package for the eventual change of enabling the
TypeScript `useUnknownInCatchVariables` option. This option provides additional
code safety by ensuring that the catch clause variable is the proper type before
attempting to access its properties. Similar changes will be needed in the other
packages in the repository prior to enabling `useUnknownInCatchVariables`.
Paths within the `angular.json` file should be relative to the location of the `angular.json` file.
The `ngswConfigPath` option was incorrectly using the current working directory for a base path when
a relative configuration path was specified. Most of the time this would work as a build command usually
is executed from the root of the workspace. However, this may not always be the case and for those cases
the actual workspace root is now used to resolve the full path for the service worker configuration file.
During the build initialization phase, many paths are converted back and forth between multiple normalized forms. These conversions involve potentially expensive string operations. The majority of the custom path `normalize` function from `@angular-devkit/core` usages have now been removed in favor of the Node.js builtin path functions. This change reduces the need to perform additional string manipulation where possible.
`inquirer` has a number of depedencies which slow down module resolution when importing (~138ms) by lazy loading this module we remove this overhead when prompts are not needed.
.substr() is deprecated so we replace it with .slice() which works similarily but isn't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
Node.js v12 will become EOL on 2022-04-30. As a result, Angular CLI v14 will no longer support Node.js v12.
BREAKING CHANGE:
Support for Node.js v12 has been removed as it will become EOL on 2022-04-30. Please use Node.js v14.15 or later.
During the build initialization phase, many paths are converted back and forth between multiple normalized forms. These conversions involve potentially expensive string operations. The majority of the custom path `resolve` function from `@angular-devkit/core` usages have now been removed in favor of the Node.js builtin path functions. This change reduces the need to perform additional string manipulation where possible.
BREAKING CHANGE:
The deprecated `showCircularDependencies` browser and server builder option has been removed. The recommended method to detect circular dependencies in project code is to use either a lint rule or other external tools.
In some cases unexpected files may be provided which can cause to unsupported or broken behaviour.
One such use-case is users can provide TypeScript files as `scripts` input, this would not be processed by the TypeScript compiler, see: https://github.com/angular/angular-cli/issues/17125 and would cause the build to fail with a an unhelpful error message during optimization as the JS optimizers cannot parse TypeScript input.
BREAKING CHANGE:
`browser` and `karma` builders `script` and `styles` options input files extensions are now validated.
Valid extensions for `scripts` are:
- `.js`
- `.cjs`
- `.mjs`
- `.jsx`
- `.cjsx`
- `.mjsx`
Valid extensions for `styles` are:
- `.css`
- `.less`
- `.sass`
- `.scss`
- `.styl`
Currently when making a change while serving a localized application, duplicate
translation warnings appear for every translation id. This fixes that by
replacing the whole translation object with a new one each time translations
are loaded.
fixes#22398
Previously, we used to delete the temporary emitted JS and map files. However this causes a problem in watch mode, as Webpack will not re-emit these deleted files during the next incremental re-build.
With this change we now delete the entire temporary directory when the process is being terminated instead of a file by file bases.
Closes#22395
With every build-angular release, previously created cache entries get stale and are no longer used. This causes the cache to keep growing as older files are not purged.
With this change we automatically purge entries that have been created with older version of build-angular and can no longer be used with the current installed version.
Closes#22323
In some cases we don't ship certain locales, or they map to files which are named only the language IDs. Example `en-US`, which it's locale data is available from `@angular/common/locales/en.mjs`
Closes#22285
When using i18n with the dev server, the translation files will now be linked as a dependency to any file containing translated text. This allows translation files to be watched and the application to be rebuilt using the changed translation files.
Closes#16341
There was previously the potential for two workers to complete quickly at the same time which could result in one of the results not being propagated to the remainder of the system. This situation has now been corrected by removing the worker execution at a later point in the process.
(cherry picked from commit 802b1b0378c1816dbfd8f4320b5d69e82f0c7aa6)
With this change we unify most of the webpack configuration into the common configuration. A number of lengthy functions and code portions have been moved into a seperate file to make the configuration easier to follow.
This change brings in a security fix causes was causes by an outdated dependency. See https://github.com/GoogleChromeLabs/critters/pull/82 for more information.
Also, remote stylesheets are excluded from processing, were previously this caused build failures.
Closes#20794
Temporary JavaScript application files that have been queued for i18n processing are now removed immediately after reading their content. This reduces the on-disk size of temporary files as well as reduces the needed disk access during the final asset copy phase of the i18n inlining process. Additional debug logging has also been added to the i18n inlining process which can be enabled via the `NG_DEBUG=1` environment variable.
Currently, using 2 Angular applications from the same workspace on the same page causes a conflict because both of the webpack runtime chunks naming are the same.
With this change we configure the runtime chunk name to be inferred from the project name. This also results in reducing unnecessary file reads which Webpack needs to do to infer the name from the workspace package.json.
For more information about this option see: https://webpack.js.org/configuration/output/#outputuniquenameCloses#21957
With this change we disable critical css inline by default. The main motivations are the following issues #20760 and #20864.
BREAKING CHANGE:
Inlining of critical CSS is no longer enable by default. Users already on Angular CLI version 12 and have not opted-out from using this feature are encouraged to opt-in using the browser builder `inlineCritical` option.
The motivation behind this change is that the package used to parse the CSS has a number of defects which can lead to unactionable error messages when updating to Angular 13 from versions priors to 12. Such errors can be seen in the following issue #20760.
```json
"configurations": {
"production": {
"optimization": {
"styles": {
"inlineCritical": true,
}
},
...
}
```
Persistent disk build cache is now enabled by default. A number of options have been added to allow fine tuning of the cache.
The options can be configuration in `cli.cache` section in the `angular.json` as shown below.
- `enabled`: Configure whether disk caching is enabled. Defaults to `true`
- `environment`: Configure in which environment disk cache is enabled. Valid values `ci`, `local` or `all`. Defaults to: `local`
- `path`: cache base path. Defaults to `.angular/cache`
DEPRECATED: `NG_BUILD_CACHE` environment variable option will be removed in the next major version. Configure `cli.cache` in the workspace configuration instead.
BREAKING CHANGE: `NG_PERSISTENT_BUILD_CACHE` environment variable option no longer have effect. Configure `cli.cache` in the workspace configuration instead.
```json
{
"$schema": "./node_modules/@angular/cli/lib/config/schema.json",
"version": 1,
"cli": {
"cache": {
"enabled": true,
"path": ".custom-cache-path",
"environment": "all"
}
}
...
}
```
This is a follow-up to fb210e5b747ce0351dd9ee7d482770b9cfa71133 which
added support for the ESM-variant of the `@angular/localize` package,
and also prepared for the `tools/` secondary entry-point we will expose
as of v13.
Unfortunately this change currently does not pass-through the ESM-loaded
plugin creators as the option (which is passed to the Babel plugin) is
incorrect. This was hidden due to a type cast. This commit fixes the
issue and also ensures TS would complain in the future if the option
names differ.
Previously, the search for a locale's data when using i18n was performed by a series of file system accesses that searched through the `@angular/common` package. The search is now conducted via Node.js module resolution which has several advantages. The internal structure of the package is no longer assumed and allows the `@angular/common` package to change its internal implementation without affecting the locale data search. File extensions of the locale data files are also not hard-coded as only the name of the locale data is needed to perform a search. There are also less direct file system access calls and the search can leverage whatever internal caching Node.js performs during module resolution.
With the Angular CLI currently being a CommonJS package, this change uses a dynamic import to load `@angular/localize` which may be ESM. CommonJS code can load ESM code via a dynamic import. Unfortunately, TypeScript will currently, unconditionally downlevel dynamic import into a require call. require calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import.
Absolute import paths, especially on Windows, must be `file://` URLs when using ESM. Otherwise, Windows drive letters (e.g., `C:`) would be interpreted as a protocol instead of a drive letter when performing the import.
With the Angular CLI currently being a CommonJS package, this change uses a dynamic import to load `@angular/service-worker/config` which may be ESM. CommonJS code can load ESM code via a dynamic import. Unfortunately, TypeScript will currently, unconditionally downlevel dynamic import into a require call. require calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import.
This is a followup PR for #21771 that addresses partial compilation linker usage.
With the Angular CLI currently being a CommonJS package, this change uses a dynamic import to load `@angular/compiler-cli/linker[/babel]` which may be ESM. CommonJS code can load ESM code via a dynamic import. Unfortunately, TypeScript will currently, unconditionally downlevel dynamic import into a require call. require calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import.
This uses a dynamic import to load `@angular/compiler-cli` which may be ESM. CommonJS code can load ESM code via a dynamic import. Unfortunately, TypeScript will currently, unconditionally downlevel dynamic import into a require call. require calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import.
