build(deps-dev): bump postcss-selector-parser from 6.1.2 to 6.1.4 in /web

[dependabot]

Bumps postcss-selector-parser from 6.1.2 to 6.1.4.

Release notes

Sourced from postcss-selector-parser's releases.

6.1.4

• fix: tolerate non-node children when serializing selectors

6.1.3

• Fix CVE-2026-9358 (NVD) / SNYK-JS-POSTCSSSELECTORPARSER-16873882 via backport of (#316 by @​MoOx)

Changelog

Sourced from postcss-selector-parser's changelog.

Changelog of postcss-selector-parser

7.1.5 - 2026-08-07

• fix: don't treat a non-prefix token before | as a namespace (#324 by @​spokodev)
• fix: preserve whitespace before a * namespace in attribute selectors (#325 by @​spokodev)
• fix: TypeError on unclosed [, ( and trailing | (#330 by @​theRizwan)

7.1.4 - 2026-06-11

• fix: tolerate non-node children when serializing selectors

7.1.3 - 2026-06-11

• Improve fix CVE-2026-9358 (NVD) / SNYK-JS-POSTCSSSELECTORPARSER-16873882 (clone/walk)

7.1.2 - 2026-06-09

• Fix CVE-2026-9358 (NVD) / SNYK-JS-POSTCSSSELECTORPARSER-16873882 (#316 by @​MoOx)

7.1.1

• perf: replace startsWith with strict equality (#308)
• fix(types): add walkUniversal declaration (#311)

7.1.0

• feat: insert(Before|After) support multiple new node

7.0.0

• Feat: make insertions during iteration safe (major)

Commits

• 4a7e4e3 7.1.4
• e2021c5 fix: tolerate non-node children when serializing selectors
• 7893b74 7.1.3
• 5bc698c Improve fix CVE-2026-9358 (NVD) / SNYK-JS-POSTCSSSELECTORPARSER-16873882 (clo...
• db32327 run oxfmt
• 16e2581 simplify deps (#319)
• b185e20 Add description in package.json + full repo url
• de415f1 Add Tidelift security notice
• c4f2c8c CI: make Node 14 test job lockfile-v3 compatible (#318)
• 4e93663 Fix test run on node < 20
• Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by moox, a new releaser for postcss-selector-parser since your current version.

[waterbro-8]

@dependabot rebase

[dependabot]

Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry!

If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request @dependabot recreate.

[PeterGuy326]

Independent review: the diff is limited to the Web lockfile and upgrades postcss-selector-parser to the patched 6.1.4 release. The Web audit is clean at the configured high threshold and required CI is green. Approving for squash auto-merge.

[waterbro-8]

Verification comment on the exact head. This is not an approve, not a request-changes, and not acceptance. I took no write action here: no review submitted, no "Update branch", no change to the auto-merge queue. Two disclosures first:

1. The last two pushes to this branch were made through my account (waterbro-8; both Merge branch 'main' commits, committer web-flow). So I am not an independent reviewer of the branch state — and under require_last_push_approval a review from me would be void regardless. The review this PR is still missing is Bindy-lbb's, not mine.
2. auto_merge is queued on this PR (enabled by PeterGuy326, squash, "after independent review and green required checks"). Anything that satisfies the required conditions merges this without a further human step. I deliberately did not do one.

Everything below was executed against a3bfe8843fef857a9569e8c242243f860b7a9c2b, not read off the diff. Provenance pinned first: unpacked the codeload tarball for that sha, git init + git add -A + git write-tree → d8710ff9c371bd6d0c49213c429ed47aadbaf7b5, byte-equal to commits/a3bfe884…'s commit.tree.sha. The base tree is 7a194f1eba4167d54bd46cf84cdbe86e00532319 (still current main).

Scope

diff -rq base head over the two whole trees returns exactly one path: web/package-lock.json, three lines — version, resolved, integrity of the single hoisted node_modules/postcss-selector-parser entry ("dev": true). web/package.json is byte-identical. Nothing else in the repository changes.

Does it do the thing it claims

$ (base/web) npm audit --package-lock-only --audit-level=low   →  1 low severity vulnerability
                                                               postcss-selector-parser  6.1.0 - 6.1.2
                                                               GHSA-w9m9-85wc-3x92
$ (head/web) npm audit --package-lock-only --audit-level=low   →  found 0 vulnerabilities

Matches the advisory's own ranges (>= 6.1.0, < 6.1.3, first patched 6.1.3). The bump goes past the minimum fix to 6.1.4, which additionally carries the "tolerate non-node children when serializing selectors" backport.

6.1.4 is also the ceiling available here, not a shortfall: the registry's legacy-v6 dist-tag is 6.1.4 and no newer 6.x exists, while the two consumers declare postcss-nested → ^6.1.1 and tailwindcss → ^6.1.2. Reaching 7.1.6 would be a major across Tailwind v3, which is a different piece of work.

No copy is left behind. find . -name package-lock.json returns exactly one file in the whole repo, and postcss-selector-parser appears in it once (hoisted) — no nested duplicate pinning a vulnerable version.

Is the lockfile still consistent

This is the real risk on a Dependabot branch that carries two human merge commits, so I checked it rather than assuming:

• npm install --package-lock-only from head's own package.json + lockfile reproduces the committed lockfile byte-for-byte. The lock is what npm's resolver produces, not a hand-merged artifact.
• Control: the same command on base keeps 6.1.2 (a plain resolve preserves a satisfying pin), so head's 6.1.4 is a deliberate npm audit fix-style raise, which is the intended semantics of this PR.
• npm ci succeeds on both trees (401 packages).

Functional impact: none measurable

$ (head/web) npm run build   →  ✓ built
$ (base/web) npm run build   →  ✓ built
$ diff -rq base/web/dist head/web/dist
   (no differences)

The two build trees are byte-identical, including the CSS bundle that this package actually feeds: same content-hashed filename index-CYthvglx.css, same md5 b1c7053c0d4f837dc9d61c0d17926c6e, 39913 bytes each. There is no observable change in the shipped artifact.

CI covers install / audit / lint / type-check / build on this head (job 101417051454, all five steps success, log shows found 0 vulnerabilities). It does not cover the web unit tests — the web job in .github/workflows/ci.yml:250-266 has no test step and no leg in the file invokes vitest. That gap is not introduced by this PR, and it is what PR #169 addresses. I closed it locally: npx vitest run → 67 passed / 6 files on both base and head.

Supply chain

The integrity value is not just transcribed — https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-6.1.4.tgz (45101 bytes) hashes to exactly sha512-bIoJLOmjCO1S9XdY/DcnR5hJxvrDir1PbGChrzXG3vw0/FOliy/fA3dmdhQ441kah4gKv+TwckGzex6wNS5cnQ==. Same method validated against 6.1.2 so the check itself is not vacuous.

Is the mitigation actually wired in the vendored code

grep -c maxNestingDepth over 6.1.2's dist/ → zero occurrences. In 6.1.4 the option is resolved at dist/parser.js:104 and enforced at dist/parser.js:667 (nesting depth exceeds the maximum of …), and dist/processor.js threads it into both the parse and the stringify path (_stringifyOptions feeding root.toString(…)). The DoS bound is present in the code that ships, not only in a signature.

Four notes, none blocking

1. This PR unblocks no gate. web/package.json's audit script is npm audit --omit=dev --audit-level=moderate && npm audit --audit-level=high; this advisory is low and dev: true, so both commands return rc=0 on base — verified by running them. PR fix(ci): add vitest to Web leg and retry transient audit failures #169's replacement wrapper (web/audit-retry.mjs) keeps the same two thresholds, so this will not become mandatory later either. It is hygiene, and correct hygiene.
2. Dependabot has lost ownership of this branch. My @dependabot rebase on 2026-09-06 was refused ("edited by someone other than Dependabot") because of those merge commits. Every future move of main will need another human merge here. @dependabot recreate would hand it back and currently costs nothing — the only content is the three-line bump.
3. No CHANGELOG entry, consistent with the one merged Dependabot precedent in this repo (build(deps-dev): bump browserslist from 4.28.2 to 4.28.8 in /web #159, also lockfile-only, merged 2026-09-03). Adding one now would land in the ## [Unreleased] insertion point that has already collided across fix(npm): bound Windows cache-lock contention retries #137 / fix(cli): redact malformed URLs and request build errors #164 / chore(release): sync every version surface to 0.1.2 #168×fix(ci): add vitest to Web leg and retry transient audit failures #169; if maintainers want a ### Security line it should be coordinated with chore(release): sync every version surface to 0.1.2 #168's release section rather than tacked on here.
4. Interaction with chore(release): sync every version surface to 0.1.2 #168: both touch web/package-lock.json. From the true merge base 7a194f1, git merge-file -p --diff3 of the two lockfiles returns rc=0 with zero conflict markers, and the merged result carries both version: 0.1.2 at the lines chore(release): sync every version surface to 0.1.2 #168's validator pins (3 and 9, unshifted) and postcss-selector-parser: 6.1.4. Text-mergeable is the whole story for a lockfile — but note chore(release): sync every version surface to 0.1.2 #168's body states v0.1.2 = the 7 commits up to 7a194f1, and build(deps-dev): bump postcss-selector-parser from 6.1.2 to 6.1.4 in /web #160 merging first makes that 8. Same staleness shape as fix(ci): add vitest to Web leg and retry transient audit failures #169, and not a defect in this PR.

Gate state as of writing

base = current main tip, ahead 3 / behind 0, mergeable=true, mergeable_state=blocked, 15/15 check-runs success on this head (one row per name, no history aggregation artifact), 3 workflow runs all completed/success at attempt 1, 0 review threads, requested_reviewers=[Bindy-lbb, waterbro-8], and one APPROVED from PeterGuy326 dated after the last push. reviewDecision reads APPROVED while mergeable_state reads blocked.

I am not claiming why the second condition is unmet. The rules live in an org-level ruleset and orgs/bytefolk/rulesets needs admin:org, which I don't have, and the repo's own rulesets cover tags only. Same "two code-owner approvals on head and still blocked" reading came out of #167 on 2026-09-07, so I won't extrapolate a mechanism from one sample. Reporting the shape only: the outstanding item on this PR is a review from the remaining requested reviewer, and it is not obtainable from me.

Repro

curl -sfL -o head.tgz https://codeload.github.com/bytefolk/mem/tar.gz/a3bfe8843fef857a9569e8c242243f860b7a9c2b
tar xzf head.tgz && cd mem-a3bfe884*/web
npm install --package-lock-only          # byte-identical lockfile ⇒ resolver agrees
npm ci && npm run build && npx vitest run
npm audit --package-lock-only --audit-level=low   # found 0 vulnerabilities

[sun-970]

Resolved by #192 (postcss-selector-parser already at 6.1.4 on main).

[waterbro-8]

Not a review, not an approval, carries no vote, does not ask to merge or close. No write action: no review submitted, no Update branch, no label or assignee change, nothing closed, no push, no Dependabot alert operated on.

Increment only. My 09-08 comment on this head (5578166540) already established the scope (3 lines), the advisory arithmetic, the lockfile self-consistency, the byte-identical build output, the integrity hash, and that Dependabot has lost this branch. I am not restating any of it. What follows is what became true after that comment, and what is still missing a measurement in sun-970's "Resolved by #192".

Permission readout for bytefolk/mem at posting time: {"admin":false,"maintain":false,"pull":true,"push":true,"triage":true}.

1. 负责人

• Author is dependabot[bot], so per "Dependabot 的修复指定真人接手" this still has no named human taker: assignees: [], requested_reviewers: ['Bindy-lbb','waterbro-8'].
• Not me as a reviewer — I pushed to this branch, so under require_last_push_approval a vote from me is void and I will not submit one. And not me as a closer: holding maintain/admin is what closing requires, and I hold neither.

2. This PR is now a provably empty change

Measured against the current main tip 87db0dfe0507be2190fe2fdcce0e267be8224f4d, which is #192's merge commit (merged_at 2026-09-10T07:25:59Z, author PeterGuy326, one file, web/package-lock.json +50/−50).

• main already carries this PR's exact entry. The two lock blobs are the same size (221,544 B) but distinct objects — main 28a95f0b2f19ddccfe0e4ad2e2a3b247fd82c2f2 vs this head 6343815d63cb9b14beffaa823196410e190d2868 — and the parsed postcss-selector-parser entry is equal field-for-field: version 6.1.4, integrity sha512-bIoJLOmjCO1S9XdY/DcnR5hJxvrDir1PbGChrzXG3vw0/FOliy/fA3dmdhQ441kah4gKv+TwckGzex6wNS5cnQ==.

• The three-way merge contributes nothing. Against the true merge base 7a194f1eba4167d54bd46cf84cdbe86e00532319, whose entry is still 6.1.2 — so both sides moved it independently and identically:

  git merge-file -q --theirs main.lock base.lock head.lock   # rc=0, zero conflict markers
  cmp main.lock <result>                                     # identical

  The merged result is byte-for-byte equal to main's file: merging this PR today changes 0 bytes in the repository. --theirs never fired; there was nothing to resolve.

• The only 9 lock entries the two files still disagree on are ones where this head is behind main (vitest + six @vitest/* at 4.1.10 vs main's 4.1.11, js-yaml 4.3.1 vs 4.3.2). base → main differs on 10 entries; base → this head on exactly 1.

• Consequence for the one bot path left: @dependabot recreate would now produce an empty PR as well, since 6.1.4 is already what main resolves. That is different from what I wrote on 09-08 ("currently costs nothing") — then it would have re-created the bump; now there is no bump left to re-create.

3. The alert closed itself off the default branch, not off a human

This is the part "Resolved by #192" asserts without showing, and it is what decides whether "take the bump" still means anything:

• Dependabot alert 75 (postcss-selector-parser, low) now reads state = fixed with dismissed_by = null and dismiss_reason = null — GitHub closed it because the default branch stopped being vulnerable, which is exactly what chore(web): refresh audited development dependencies #192 did at 07:25:59Z today. Nobody dismissed it; those two fields are how you tell the two apart.
• The repo's open set right now is 6 alerts, none of them this package: google.golang.org/grpc 74 (high), 78 (high), 79 (medium); pypdf 71, 72, 73 (medium). Numbers are alert ids, written without # so they do not link to issues.

4. 回归 / CI 证据 on the exact current head a3bfe8843fef857a9569e8c242243f860b7a9c2b

commits/<head>/check-runs deduplicated per name by max check_suite.id — 15 records, 15 names, all completed / success: Agent host MCP contract, Conventional title and linked issue, Deployment profiles, Go, HTTP, CLI and MCP lifecycle, Offline recall benchmark, PostgreSQL integration, Web, Web memory and transfer acceptance, Worker, Workflow, scripts and Compose, npm wrapper, npm wrapper compatibility (node18-linux), npm wrapper compatibility (node20-linux), npm wrapper compatibility (node24-windows).

• Reviews on this head: exactly one — PeterGuy326 APPROVED, 2026-09-06T03:13:36Z, commit_id a3bfe8843fef. Inline pulls/160/comments is empty.
• mergeable = true, mergeable_state = behind; compare/main...head = diverged / ahead_by 3 / behind_by 2.
• One gap to name rather than read as "green": these 15 legs do not include CodeQL (go), CodeQL (python), CodeQL (javascript-typescript), Dependency review, Dependabot or OpenSSF Scorecard. All six exist on today's main (21 records / 20 names; Dependency review there is completed / skipped on a push event, OpenSSF Scorecard success from a main run). A pull_request run uses the workflow files on the head branch, so this branch could not show the CodeQL / dependency-review legs that arrived via ci: enable free security baseline (#166) #167 and chore(web): refresh audited development dependencies #192 without a main sync — and Scorecard triggers only on push: [main] / schedule / workflow_dispatch, so it will appear on no PR here regardless. Which is moot for a PR that changes 0 bytes, but it is why "15/15 green" is not the same set of gates as main's.

5. What is left, and whose it is

No fix commit is possible — there is no defect: the update this PR exists to make is already installed on main, and its own advisory is closed. So the remaining choice is bookkeeping, and per "别平行重复改，也先不要关 PR" and "本轮先不合并" I left it open and touched nothing: either close it as subsumed by #192 (pointing at §2 and §3 above), or keep it as a record until a release boundary. That call belongs to Bindy-lbb / PeterGuy326.