This can drastically reduce memory usage; especially in cases where bundled code modules contain individual sourcemap comments and vendor sourcemaps are disabled. Enabling the vendor sourcemap option has the side effect of removing all individual module sourcemap comments and as a result removes the potential for those comments to be found and processed.
When having differential loading enabled we only add the `sourceMappingURL` comment when optimization is enabled, because we only process these bundles when we enabling optimization.
With this change we now process such bundles even when optimization is disabled and add `sourceMappingURL` when source maps are enabled and not hidden.
Closes#16522
Fixes#15792.
Previously, budgets would include content for both versions of a differential build. Thus the `initial` budget would count content from the ES5 **and** ES2015 bundles together. This is a very misleading statistic because no user would download both versions. I've updated the budget calculators to take this into account and generate size values for both builds which are then checked independently of each other.
The only calculators I changed are the `InitialCalculator` (for computing `initial` bundle sizes) and `BundleCalculator` (for computing named bundles). Since budgets are handled by Webpack for builds without differential loading, the `initial` bundle will always have those two sizes. The `BundleCalculator` might reference a bundle which does not have differential loading performed (such as a CSS file), so it emits sizes depending on whether or not multiple builds were found for that chunk.
Most of the other calculators don't really need to take differential loading into account. `AnyScriptCalculator` and `AnyCalculator` already apply on a file-by-file basis, so they generate sizes for both build versions already. `AnyComponentStyleCalculator` only applies to CSS which does not have differential builds.
The wierd ones here are `AllCalculator` and `AllScriptCalculator` which reference files with and without differential builds. Conceptually, they should be separated, as a "total" budget specified by an app developer probably wanted it to mean "the total resources a user would have to download", which would only be one differential build at a time. However, I don't see a good way of identifying which assets belong to which differential build. Even if an asset belongs to a chunk with differential builds, we don't know which build takes which assets into account. I decided to leave this for the time being, but it is probably something we should look into separately.
Since budgets take differential loading into account, users might reasonably want to set different budgets for different builds (ie. "initial-es2015 bundle should be capped at 100k, but initial-es5 bundle can go to 150k"). That's more of a feature request, so I also left that out for a future PR.
Refs #15792.
Static files listed in `angular.json` were being accounted in the `initial` bundle budget even when they were deferred asynchronously with `"lazy": true` or `"inject": false`. Webpack belives these files to be `initial`, so this commit corrects that by finding all extra entry points and excluding ones which are explicitly marked by the application developer as asynchronous.
One edge case would be that the main bundle might transitively depend on one of these static files, and thus pull it into the `initial` bundle. However, this is not possible because the files are not present until the end of the build and cannot be depended upon by a Webpack build step. Thus all files listed by the application developer can be safely assumed to truly be loaded asynchronously.
Refs #15792.
This provides access to all the size information necessary because all build steps have already completed. This commit is roughly a no-op because it simply moves the budget checks (for different builds) to be executed post-build.
The lone exception is the AnyComponentStyle budget. Component stylesheet files are not emitted after the build is completed, so there is no size information to work with. Instead, these budgets are checked during a separate plugin (exected for different builds **and** non-differential builds).
This is needed as otherwise under Bazel we hit `Cannot find module '@babel/preset-env` we use `require.resolve` since this is always patched under Bazel.
This is needed as otherwise under Bazel it will fail with `Angular Compiler was detected but it was an instance of the wrong class.` when not using the linker since node_modules will be linked to `external/npm`. Under Bazel `preserveSymlinks` is to be set to true, however with the current behaviour this doesn't effect resolveLoader.
Refs #16193
This detects and filters out error messages about duplicate 3rdpartylicenses.txt. This is a short-term fix intended to get us to 9.0.x release while a follow up effort will work to properly fix this bug. Left a TODO to remove this filter once a fix is ready.
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
