ci: bump browserslist from 4.21.3 to 4.28.8 - #44
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [browserslist](https://github.com/browserslist/browserslist) from 4.21.3 to 4.28.8. - [Release notes](https://github.com/browserslist/browserslist/releases) - [Changelog](https://github.com/browserslist/browserslist/blob/main/CHANGELOG.md) - [Commits](browserslist/browserslist@4.21.3...4.28.8) --- updated-dependencies: - dependency-name: browserslist dependency-version: 4.28.8 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
![clippy-qa[bot]](https://avatars.githubusercontent.com/in/4024528?s=60&v=4){kind=small}
There was a problem hiding this comment.
Clippy reviewed this pull request
This PR bumps browserslist from 4.21.3/4.23.3 to 4.28.8 by modifying only yarn.lock. All semver range consolidations are valid, all removed lock-file entries have been confirmed to have no remaining consumers, integrity hashes are correctly formatted, and the lock file is internally consistent. One minor efficiency nit was introduced by Yarn 1's deduplication behavior.
1 finding — 0 blocking · 1 nit · 0 pre-existing
No blocking findings — nothing in scope blocks the merge, and no thread I opened is unresolved. Approval on this base branch is a human's to give.
clippy-review: verdict=clean event=COMMENT normal=0 nit=1 pre_existing=0 inline=1 body=0 unresolved=0 head=502bd21
| integrity sha1-m/tzY/7//4emzbbNk+QF7DxLbyY= | ||
|
|
||
| escalade@^3.1.1, escalade@^3.1.2: | ||
| escalade@^3.1.1: |
There was a problem hiding this comment.
nit: escalade dual-install introduced by this bump
Before this change, a single lock-file entry escalade@^3.1.1, ^3.1.2 resolved to 3.1.2, serving all consumers. After the bump, update-browserslist-db@1.3.2 now requires escalade@^3.2.0, which cannot satisfy the existing ^3.1.1 pin at 3.1.2, so Yarn 1 adds a second entry (escalade@^3.2.0 → 3.2.0). Since 3.2.0 satisfies ^3.1.1 (≥3.1.1 <4.0.0), bumping the ^3.1.1 entry's resolved version to 3.2.0 and collapsing the two entries would eliminate the duplicate install. The current state is not incorrect — both copies are the right version for their consumers — but it means two copies of escalade exist in node_modules. Running yarn upgrade escalade after this merge would clean it up.
There was a problem hiding this comment.
Clippy reviewed this pull request
This PR is a routine Dependabot browserslist bump from 4.21.3/4.23.3 to 4.28.8. All semver ranges are correctly satisfied, the new transitive dep baseline-browser-mapping is a data-only package with sha512 integrity and no install scripts, and all removed entries had no other consumers. Two minor non-blocking items survive verification — neither was introduced by this PR in a meaningful way.
2 findings — 0 blocking · 1 nit · 1 pre-existing
1 finding could not be anchored to the diff, so they are here instead:
yarn.lock:9933— pre-existing: whatwg-fetch uses legacy registry.npmjs.org URL and weak sha1 integrity hash Line 9935:resolved "https://registry.npmjs.org/whatwg-fetch/-/whatwg-fetch-0.11.1.tgz"withintegrity sha1-6D3ded.... Every other package in the lock resolves fromregistry.yarnpkg.comand usessha512. This entry predates the PR. SHA-1 integrity is sufficient for detecting accidental corruption but is cryptographically weak against targeted attacks; regenerating the lock with a current Yarn version would upgrade both the URL and hash format.
No blocking findings — nothing in scope blocks the merge, and no thread I opened is unresolved. Approval on this base branch is a human's to give.
clippy-review: verdict=clean event=COMMENT normal=0 nit=1 pre_existing=1 inline=1 body=1 unresolved=0 head=502bd21
| resolved "https://registry.yarnpkg.com/escalade/-/escalade-3.1.2.tgz#54076e9ab29ea5bf3d8f1ed62acffbb88272df27" | ||
| integrity sha512-ErCHMCae19vR8vQGe50xIsVomy19rg6gFu3+r3jkEO46suLMWBksvVyoGgQV+jOfl84ZSOSlmv6Gxa89PmTGmA== | ||
|
|
||
| escalade@^3.2.0: |
There was a problem hiding this comment.
nit: Redundant escalade install: 3.1.2 and 3.2.0 both ship when 3.2.0 satisfies all consumers
The new update-browserslist-db@1.3.2 requires escalade "^3.2.0", causing Yarn v1 to split what was previously a single escalade@^3.1.1, ^3.1.2 entry into two: one at 3.1.2 (for yargs@16/yargs@17) and one at 3.2.0. Since ^3.1.1 means >=3.1.1 <4.0.0, version 3.2.0 satisfies it, so two copies ship unnecessarily. Yarn v1 won't auto-deduplicate across range keys — a manual yarn-deduplicate --packages escalade run would consolidate both to 3.2.0 and eliminate the duplicate install.
There was a problem hiding this comment.
Clippy reviewed this pull request
This is a yarn.lock-only automated bump of browserslist from 4.21.3/4.23.3 to 4.28.8, with consistent transitive updates (caniuse-lite, electron-to-chromium, node-releases, update-browserslist-db, plus a new baseline-browser-mapping dep). The lockfile is internally consistent — all resolved versions satisfy their declared semver ranges and all integrity hashes are present. One plausible behavioral side-effect is noted: eslint-plugin-escompat (active via plugin:github/react) resolves its browser targets from the default browserslist query against the updated caniuse dataset, so lint error thresholds could shift silently.
1 finding — 0 blocking · 1 nit · 0 pre-existing
1 finding could not be anchored to the diff, so they are here instead:
.eslintrc.yml:18— nit: eslint-plugin-escompat browser targets shift silently with updated caniuse data The project extendsplugin:github/react(line 18 of.eslintrc.yml), which pulls ineslint-plugin-escompatviaeslint-plugin-github@^4.10.1.escompatresolves its supported-browser set by running the default browserslist query (> 0.5%, last 2 versions, Firefox ESR, not dead) against the installedcaniuse-litedata. This bump upgradescaniuse-litefrom 1.0.30001653 to 1.0.30001810, meaning the resolved browser set changes without any query change. APIs that were previously below the coverage threshold might now be above it (or vice versa), so a lint pass that was clean before the bump could gain newescompaterrors — or silently stop catching real incompatibilities — on the nextyarn lintrun. The fix is to add an explicitbrowserslistquery topackage.json(or a.browserslistrc) so the targets are stable across data bumps.
No blocking findings — nothing in scope blocks the merge, and no thread I opened is unresolved. Approval on this base branch is a human's to give.
clippy-review: verdict=clean event=COMMENT normal=0 nit=1 pre_existing=0 inline=0 body=1 unresolved=0 head=502bd21
Bumps browserslist from 4.21.3 to 4.28.8.
Release notes
Sourced from browserslist's releases.
... (truncated)
Changelog
Sourced from browserslist's changelog.
... (truncated)
Commits
f2f2e6cRelease 4.28.8 versiond0787c8Update dependenciesfcf8fa9Merge pull request #939 from Jaybhade/fix/baseline-kaios-without-downstream57ecd64fix: support "including kaios" without downstream093a0f6Update EM bannerb637868Release 4.28.7 version313f465Update dependenciesc935c5aFix regexp performanced7e9e65Rewrite structure parsing to make it always fastec4a55eFix import orderMaintainer changes
This version was pushed to npm by GitHub Actions, a new releaser for browserslist since your current version.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.