chore(deps): prune stale pnpm overrides, move workspace pins to the catalog - #4101

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
astryx	Ready	Preview	Aug 20, 2026 2:55pm

PR Analysis Report

📚 Storybook Preview

View Storybook for this PR
GitHub Pages may take up to a minute to hydrate after deploy.

🧪 Sandbox Preview

View Sandbox for this PR
GitHub Pages may take up to a minute to hydrate after deploy.

No new or modified components detected.

Bundle Size Summary

No component packages changed.

Accessibility Audit

Status: No accessibility violations detected.

_{Generated by PR Enrichment workflow | Storybook | Sandbox | View full report}

Rebased onto main (08c99b8) to resolve the pnpm-workspace.yaml conflict. The lockfile was regenerated with pnpm install rather than hand-merged.

How the conflict was resolved

This PR's pruning and catalog move are kept as-is. Every security floor main gained after this branch was cut is preserved, since they postdate the audit in the original commit message:

• postcss ^8.5.10 → ^8.5.18, dompurify ^3.4.11 → ^3.4.12 (fix(deps): resolve Dependabot alerts for postcss, fast-uri, dompurify, brace-expansion #4398)
• fast-uri ^3.1.4, brace-expansion ^2.1.2 (fix(deps): resolve Dependabot alerts for postcss, fast-uri, dompurify, brace-expansion #4398)
• sharp ^0.35.3 (fix(deps): override sharp to 0.35 to clear inherited libvips CVEs (#4400) #4449)
• the read-yaml-file 2.x lift

The pruned entries main did not touch (picomatch trio, minimatch, tmp, @babel/core, hono, and the prettier/@stylexjs/stylex catalog moves) stay pruned.

Overlap with #4402

While verifying, pnpm audit flagged two js-yaml advisories that exist on main today: the '@changesets/parse>js-yaml': '>=4.2.0' floor is unbounded, so it resolves the chain onto js-yaml 5.2.1, inside the vulnerable >=5.0.0 <=5.2.1 range.

#4402 already fixes exactly this by moving both js-yaml chains to 5.2.2 and excluding js-yaml@5.2.2 from minimumReleaseAge. I've adopted that same fix here so this branch does not regress the floor, with one deviation: the ranges are written as ^5.2.2 instead of >=5.2.2. An unbounded >= is what dragged this chain onto a vulnerable major in the first place, and a future js-yaml 6 would repeat it.

If #4402 lands first, this becomes a no-op on those two lines — happy to drop them and rebase instead. Sequencing is up to you.

Verification

• pnpm audit: 12 → 10 findings. The two js-yaml advisories clear; the remaining 10 (next ×8, @hono/node-server, brace-expansion) are identical to main's baseline, confirmed by auditing a clean worktree at 08c99b8.
• pnpm changeset status runs clean — no safeLoad error, so read-yaml-file 2.x is fine on js-yaml 5.
• pnpm check:repo passes; @astryxdesign/build and @astryxdesign/core build (5719 StyleX rules, CSS + UMD emitted).

Lint was failing on the rebase — pushed a fix.

What broke

Pruning minimatch: ^9.0.7 let @eslint/config-array resolve minimatch 10, which calls the named expand export. main's brace-expansion: ^2.1.2 floor (added in #4398, after this branch was cut) pins brace-expansion to 2.x, which only has the default CJS export:

TypeError: (0 , brace_expansion_1.expand) is not a function
    at braceExpand (node_modules/minimatch/dist/commonjs/index.js:157:41)
    at doMatch (node_modules/@eslint/config-array/dist/cjs/index.cjs:422:13)

Why the fix is to drop brace-expansion too, not to keep minimatch

^2.1.2 sits below the declared range of every consumer in the graph — minimatch@10 (via @eslint/config-array) declares ^5.0.5, minimatch@3 (via @babel/cli) declares ^1.1.7. It was a downgrade, not a floor, and it only stayed invisible while the equally stale minimatch force held minimatch on a line that still used the default export.

Unforced, each consumer resolves inside its own range — brace-expansion 5.0.7 and 1.1.16 — and ESLint runs clean. So both entries are pruned rather than one restored.

Verification

• pnpm lint: 0 errors. (Locally it also reports ~23.5k errors under apps/docsite/public/monaco/ and public/vendor/, but both are gitignored, untracked build artifacts that a fresh CI checkout does not have — the count is identical with minimatch 9 or 10, so it is unrelated noise.)
• pnpm test: 393 files / 7933 tests pass.
• pnpm audit: 10 findings, unchanged from the previous push and 2 fewer than main's 12.
• pnpm check:repo, @astryxdesign/build and @astryxdesign/core builds all pass.

The commit message and the comments in pnpm-workspace.yaml are updated accordingly — the original message described minimatch as a dedup-only force, which was right about the outcome but missed that it was entangled with the brace-expansion floor.