Make the version strategy of caniuse-lite incremental

[studioTeaTwo]

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Description

I manage so that browserslist doesn't have isEs5SupportNeeded to trun off differential loading. But the result is not stable.

caniuse-lite has its own data in json file in npm package. Both build-angular and browserslist have caniuse-lite.
Since dependencies of browserslist is incremental like caniuse-lite "^1.0.30001017" and caniuse-lite of build-angular is fixed, the judgment result of BuildBrowserFeatures can change even if the source code of the repository is the same.
Modern browsers are updated frequently, so Angular-cli may not be updated in time.

For example:

[email protected] includes "caniuse-lite": "1.0.30001019".
This version don't have the information of android chrome 79.
last 2 versions on the browserslist can return 79-78.
BuildBrowserFeatures.isFeatureSupported('es6-module') returns false, because featureStatus for android chrome 79 is undefined.

Describe the solution you'd like

The package.json of @angular-devkit/build-angular changes version dependencies of caniuse-lite incrementally like "^1.0.0".

Describe alternatives you've considered

Make the caniuse-lite included in the browserlist exactly match the caniuse-lite of the build-angular.

1. Point the version of caniuse-lite in resolutions.
2. Remove caniuse-lite in package.json, use dependiecies of package.json in browserlist.

Or, change the logic of BuildBrowserFeatures.isFeatureSupported.
It may be better to find the lowest supported version and judge the version with an inequality sign. If using caniuse-api, it can be easily. But impact on polyfill creation, etc. cannot be fully determined.

[dgp1130]

Should be reasonable to pin to ^1.0.30001019, that way it can update without needing to update Angular.

[dgp1130]

Updating this appears to cause some breakages, need to identify where they are coming from to verify that this can be properly unpinned.

In not, then we could update the dependency with each Angular minor release, so users would still get weekly updates. That's more of a fallback we aren't able to unpin this like we want to.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}