This change adds support for extracting i18n translation messages with an Ivy enabled application. This is accomplished by using the new extraction capabilities present in the `@angular/localize` package and will require version 10.1 or later of the package. Since this change uses an new extraction method, it currently must be enabled during extraction by using the `--ivy` flag. The flag is a precaution to prevent unintentional breakage for existing applications but will become the default behavior for all Ivy enabled applications in a future release.
Closes#18275
At the moment in AOT mode if a CommonJS dependency has transitive CommonJS dependency we are issue warning for both.
With this change we align the behaviour with JIT mode, where we issue warnings only for direct CommonJS dependencies or ES dependencies which have CommonJS dependencies.
Closes#18526
This change implements the capability to specify multiple translation files per locale. The specified translation files for each locale will be merged prior to localization. The Angular configuration file has been updated to allow for both a single path string or an array of path strings when specifying the translations for each locale. If the same message identifier is present in multiple translation files, a warning will currently be issued and the last file with the duplicate message identifier will take precedence.
Closes#18276
These changes simplify type usage in several places as well as cover more usage scenarios with alternate configuration option structures (for example, options that can be arrays or object literals)..
When `bundleDependencies` is turned off, webpack only bundles modules imported via relative path.
Existing check works well for import paths like `'./some/file'`,
but fails for imports traversing the dir structure up, like `'../some/file'`.
By leveraging the chunks function filter option, the test option can be reduced to only a regular expression instead of the more complex function. This change also provides support for Webpack 5.
Multiple Webpack plugins are only used when certain options are enabled. By only requiring them when needed, startup time can be reduced by potentially eliminating large dependency hierarchies from being loaded that will then be unused. This change currently only applies to plugins that are required. This limitation is due to the current webpack configuration infrastructure being synchronous which prevents dynamic import usage.
