Depending on CommonJS modules is know to cause optimization bailouts. With this change when running a browser build and scripts optimization is enabled we display a warning.
To suppress the warning for a particular package, users can use the `allowedCommonJsDepedencies` builder options.
Example:
```
"build": {
"builder": "@angular-devkit/build-angular:browser",
"options": {
...
"allowedCommonJsDepedencies": ["bootstrap"]
},
}
```
Reference: TOOL-1328
Third party libraries can attempt to write color codes to the output even though the CLI has already determined that color should not be used. The previously implemented color removal code is no longer functional since the update of ansi-colors to 4.1.0. While this appears to be a defect in the aforementioned package, the new CLI removal method not only bypasses the defect but also unneeded execution logic that the CLI does not need in this case.
Fixes: #17053
When an error occurs during ng update we currently discard the stack trace which in some cases made it hard to identify the cause of the error.
Now, we print the stack trace to a log file similarly to unhandled exceptions.
Example of CMD output;
```cmd
** Executing migrations of package '@angular/core' **
> Static flag migration.
Removes the `static` flag from dynamic queries.
As of Angular 9, the "static" flag defaults to false and is no longer required for your view and content queries.
Read more about this here: https://v9.angular.io/guide/migration-dynamic-flag
× Migration failed: x
See "C:\Users\alag\AppData\Local\Temp\ng-NgmC1G\angular-errors.log" for further details.
```
Example of log file contents:
```txt
[error] Error: x
at UpdateCommand.executeSchematic (C:\git\angular-cli\test\node_modules\@angular\cli\commands\update-impl.js:98:19)
at UpdateCommand.executePackageMigrations (C:\git\angular-cli\test\node_modules\@angular\cli\commands\update-impl.js:167:39)
at UpdateCommand.executeMigrations (C:\git\angular-cli\test\node_modules\@angular\cli\commands\update-impl.js:161:21)
at UpdateCommand.run (C:\git\angular-cli\test\node_modules\@angular\cli\commands\update-impl.js:394:38)
at async UpdateCommand.validateAndRun (C:\git\angular-cli\test\node_modules\@angular\cli\models\command.js:134:28)
at async Object.runCommand (C:\git\angular-cli\test\node_modules\@angular\cli\models\command-runner.js:201:24)
at async default_1 (C:\git\angular-cli\test\node_modules\@angular\cli\lib\cli\index.js:62:31)
```
Pass the "grep" and "invertGrep" flags through to the Angular Protractor
builder as "jasmineNodeOpts" so that individual specs within an E2E test
file can be targeted.
Fixes#13020
Set the `BROWSERSLIST_IGNORE_OLD_DATA` enviorment variable to disable Browserslist old data warning
`Browserslist: caniuse-lite is outdated. Please run next command `npm update`
See: 819c433745/node.js (L324)
Certain node packages depend on native bindings which cannot be bundled, with this fix we add a way to exclude these from being processed by the bundler.
Closes: #16348
All locale i18n options now support an object form which allows a base HREF to be defined for the locale. Each locale can now optionally define a custom base HREF that will be combined with the base HREF defined for the build configuration. By default if the shorthand form for the locale is used or the field is not present in the longhand form, the locale code will be used as the base HREF. To disable automatic augmentation a base HREF value of an empty string (`""`) can be used. This will prevent anything from being added to the existing base HREF.
For common scenarios, the shorthand form will result in the preferred and recommended outcome of each built locale variant of the application containing a defined base HREF containing the locale code.
This change ensures that both the global version and the project version Node.js version requirements are met before the CLI executes a command. Previously an older global version of the CLI would allow a newer project version to execute even if the project version had more strict Node.js version requirements. The Node.js version is now checked twice. Once in an ES5 safe script to ensure that ancient Node.js versions are not in use. And secondly in the CLI entry code that is executed after global/project bootstrapping.
With this change we now check if the current CLI version is the latest published version. If it is not, we install a temporary version to run the `ng update` with.
* feat(@angular-devkit/core): update schema to support new i18n options
"projects": {
"my-app": {
"projectType": "application",
"schematics": {},
"root": "",
"i18n": {
"sourceLocale": "en-US",
"locales": {
"fr": "src/locale/messages.fr.xlf"
}
},
"sourceRoot": "src",
...
}
}
* feat(@angular-devkit/build-angular): add new i18n options to browser and server builders
With this change we add `translateLocales` as new options for i18n in browser and server builders.
We also deprecate the following options;
* i18nLocale
* i18nFormat
* i18nFile
* feat(@angular-devkit/build-angular): deprecate `i18nFormat` and `i18nLocale` options of `extract-i18n` builder
Option `i18nFormat` has been deprecated in favor of `format` and `i18nLocale` option has been deprecated in favor of the `sourceLocale` sub option of the `i18n` project level option.
* feat(@angular/cli): add alias of `i18n-extract` for `x18n` command
* refactor: rename `translateLocales` to `localize`
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
Whenever an unhandled exception during command processing occurs, the message and stack trace will be saved to a debug log located in a temporary directory. The user will be informed of the log location as well as the exception message and instructions to file a bug report at the GitHub repository.
Node.js 10+ provides built-in functionality to test for color support based on chalk's `supports-color` package as well as several others. This alleviates the need for custom code or third-party packages to determine color support. In addition for this PR, the `ansi-colors` package is added to the CLI which provides color, cross-platform symbol, and style/color removal support. The package is light-weight, contains typings, and has no dependencies. The removal support is leveraged to remove all styling from logger messages when color is not supported. This removes a current defect in which color/styling is still displayed if generated manually or via methods that do not perform supportability checks. Finally, the typically used console functions are overriden to leverage the logger to ensure that the color processing is applied to third-party code (e.g., webpack internally as well as some of its loaders and plugins) which output to the console directly.
Angular 5.0+ has a full peer dependencies setup (with 6.0+ also having a configurable runtime error check) to ensure that an appropriate version of typescript is available for compilation. Angular CLI 8.0+ does not support Angular versions prior to these and therefore the warning is redundant. For the case where the developer wishes to use an unsupported TypeScript version, the developer would need to adjust two similar but differently name settings in two different configuration files.
BREAKING CHANGE:
Root relative URLs are a standardized method to reference a resource path from the root of a host. The previous behavior of the Angular CLI prevented this from occuring and resulted in an inability to reference stylesheet assets in this manner. The initial reason for this behavior is no longer present in the internal implementation of the Angular CLI. Therefore, this now unnecessary and non-standard behavior is being phased out. If an application currently relies on this behavior, a compatibility option `rebaseRootRelativeCssUrls` has been provided for the 8.x release cycle to facilitate transition away from this non-standard and limiting behavior. The recommended method to transition is to use relative paths within the source stylesheet. This allows the build system to process and generate a full URL for the asset.
