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.
If no translation parsers could parse a translation-file
we displayed a generic error, which makes it difficult to
track down if there is a problem with the file.
https://github.com/angular/angular/pull/37909 introduces
a new `parser.analyze()` API that allows us to get hold
of the diagnostic messages from trying to parse the
translation-files.
This commit will render these messages if none of the
translation parsers are succcesful.
Note that in order to maintain compatibility with versions
of `@angular/localize` that do not have the `analyze()`
method, the commit includes a polyfill, which can be removed
after a release where we can guarantee that the method
will be available.
This change prevents webpack from removing the operator add imports from the rxjs package (for example, `import 'rxjs/add/operator/filter';`). The entire rxjs package is currently marked as side effect free from within the rxjs `package.json` but the files in the add directory intentionally contain side effects.
This change prevents import statements from being added to commonjs files when downleveling helpers are needed. These imports would then cause webpack to assume that the file is an ES module and potentially break the commonjs file.
Fixes#18284
Currently, when users use either absolute paths, or path mappings in JIT mode, we issue a warning for templateUrl and styleUrl. With this change we suppress those warning.
Closes: #18057
CI performance variability can cause test flakes in rebuild tests due to the rebuilds taking longer than expected. This change increases the 500ms debounce time for the web worker rebuild tests to 1000ms to mitigate these issues.
This change ensures that classic (ES5) script's top-level function helpers do not get overwritten by other scripts top-level functions that happen to have the same name. This is not an issue when using module script types because each module has its own scope.
We have not yet deprecated the non-global locale data modules (e.g. `@angular/common/locales/fr`) so we should not be issuing warnings about developers using them.
We recently added warning suggesting that a "global" locale should be used instead, and the previous CommonJS/AMD warning about the format of these non-global modules are just confusing for the developer.
Reference: TOOL-1388
Closes: #18123
When using the `localize` option directly importing locale data from `@angular/common` is not needed because the Angular CLI will automatically include locale data. When not using the `localize` option, most likely users meant to import the global variant of the local data.
See: https://angular.io/guide/i18n#import-global-variants-of-the-locale-data
With this change we add the functionality to also match an allowed dependency against a package name. The package name is retrieved from the rawRequest.
Previously, users needed to add the request path which in some case might be a deep import. Ex: `zone.js/dist/zone-error`. With this change adding the package name example `zone.js` will suffice.
Closes: #18058
