Fix/mass deduplication 2

[scinos]

Changes proposed in this Pull Request

Aggregation of PR's deduplicating packages:

• Deduplicate browserslist (Deduplicate browserslist #48594)
• Deduplicate babel-plugin-dynamic-import-node (Deduplicate babel-plugin-dynamic-import-node #48592)
• Deduplicate aria-query (Deduplicate aria-query #48590)
• Deduplicate autoprefixer (Deduplicate autoprefixer #48591)
• Deduplicate babel-preset-current-node-syntax (Deduplicate babel-preset-current-node-syntax #48593)

Each PR has been reviewed and approved.

[matticbot]

Test live: https://calypso.live/?branch=fix/mass-deduplication-2

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[jsnajdr]

@scinos browserslist could use further deduplication here. Now it has two versions installed, 4.14.0 and 4.14.7. caniuse-lite and autoprefixer are in a similar situation.

Noticed this when resolving lockfile conflicts with #48729.

[scinos]

I'm not sure it can be safely deduplicated, as our tree requires two different non-overlapping ranges of browserlist:

• [email protected] depends on [email protected] (fixed version, not a range)
• Other packages depends on browserslist@^4.11.1 or browserslist@^4.12.0.

Most likely react-dev-utils will work fine with [email protected], but I rather not override the version specified by a project without first understanding why react-dev-utils uses a fixed version and maybe asking them to switch to ranges.

Looks like this "explicit duplication" is very common in our repo: a basic grep tells me we have 548 packages with two or more versions, while yarn-deduplicate --list only detects 136 packages candidates to be deduplicated.

[jsnajdr]

I see, there are actually three records for browserslist in the lockfile. I haven't noticed the first, pinned one before:

1. [email protected] -> 4.10.0. That's a pinned version, nothing can be done about it.
2. browserslist@^4.0.0 + 5 other specs -> 4.14.0. All of them use carets (^) and should be flexible.
3. browserslist@^4.14.5 -> 4.14.7. This one could be deduplicated and merged into the big list above. And the whole list should deduplicate into the 4.14.7 version.

I wonder why yarn-deduplicate didn't find that records 2 and 3 can be merged into one? Maybe it got confused by record 1 somehow?

[scinos]

Very interesting! Maybe the extra record was added after I run the initial yarn-deduplicate for browserslist? Maybe it is a bug in yarn-deduplicate

It seems to detect it fine now in trunk:

Package "browserslist" wants ^4.0.0 and could get 4.14.7, but got 4.14.0
Package "browserslist" wants ^4.12.0 and could get 4.14.7, but got 4.14.0
Package "browserslist" wants ^4.6.4 and could get 4.14.7, but got 4.14.0
Package "browserslist" wants ^4.8.2 and could get 4.14.7, but got 4.14.0
Package "browserslist" wants ^4.8.5 and could get 4.14.7, but got 4.14.0
Package "browserslist" wants ^4.9.1 and could get 4.14.7, but got 4.14.0

And in fact, npx yarn-deduplicate --packages browserslist moves all specs using carets to one single version, 4.14.7

[scinos]

Actually it looks like a bad merge: the original PR correctly deduplicates all versions: https://github.com/Automattic/wp-calypso/pull/48594/files.

Edit: uh. It was re-added in f4121b7

[jsnajdr]

Interesting. In that autoprefixer deduplication, some browserslists semvers stopped being requested, so it makes sense that the browserslists record would be modified (removing an item from the list). But why it was split into two? Looking at the diff, that was not necessary at all.

[scinos]

I did those in two different PRs (actually I have a script that does each dedupe in an individual PR), but I merge them into this branch/PR to avoid creating too much noise in the deployment queue.