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.
This aligns options that do the same thing:
1) `skipSpecs` and `spec` has been deprecated in favor of `skipTests`.
2) `styleext` has been deprecated in favor of `style` since the latest is two words.
Fixes#12784
* 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
* fix(@angular-devkit/core): errors and warnings are hard to read in windows cmd
Closes#12755
* fix(@angular/cli): errors and warnings are hard to read in windows cmd
Closes#12755
