[eseidel]

Why

The docs repo has 4 open Dependabot alerts: three on DOMPurify 3.4.16 (critical, high, low; fixed in 3.4.17) and one on postcss-selector-parser 6.1.4 (medium, quadratic-time parsing of selectors, fixed in 7.1.6). This PR fixes all four where the code actually runs. It replaces #760, Dependabot's own DOMPurify bump, which failed spell-check because the word "dompurify" in its title isn't in the dictionary.

• DOMPurify comes in through mermaid, which sanitizes diagram SVGs in the browser. It's a patch bump to 3.4.17.
• postcss-selector-parser is loaded on every build by Starlight's code-block renderer (@expressive-code/core → postcss-nested). This PR updates expressive-code 0.44.0 → 0.44.3, which is within Starlight's range. That release moves to postcss-nested 7 and postcss-selector-parser 7.1.7. The lockfile also picks up @ctrl/tinycolor 4.2.0 → 4.2.1, an expressive-code dependency.
• One 6.1.4 copy remains, under tw-to-css → tailwindcss 3. tw-to-css loads its own self-contained bundle and never this copy, and we never call it (our OG renderer uses inline styles). So alert Add ios add-to-app guide, restructure android and ios releasing and add to app guides #104 is dismissed as not used, with that reason. No override.

Nothing changes for readers.

What could go wrong

The expressive-code update could change how code blocks are styled. I built the site with and without it: the HTML is identical apart from hashed asset paths, and the combined CSS is byte-identical. If it did break, code blocks would look different on any page that has them. DOMPurify 3.4.17 is a patch release; a change in sanitization would show up as mermaid diagrams rendering differently.

A local npm audit still lists the tw-to-css chain (moderate) until tw-to-css updates. GitHub shows that alert as dismissed.

Screenshots

No visible change: the built HTML and CSS are identical.

Landing

As soon as approved.

🤖 Generated with Claude Code

[eseidel]

Adversarial review (separate agent, no context from the author)

Verdict: safe to land; one claim to correct. CI is green. npm ls is valid, npm audit reports 0, and all 4 open alerts (#104, #108–#110) are covered. DOMPurify has a single copy (mermaid → 3.4.17).

1. Medium: the postcss-selector-parser override changes no code that runs, so the "byte-identical OG images" check proves nothing. tw-to-css/dist/index.mjs is a self-contained 290 KB bundle with no outside import/require; tailwind and postcss-selector-parser 6.x are compiled into it. The node_modules/postcss-selector-parser the override replaces is never loaded, and our OG renderer (src/og/renderer.tsx) uses inline styles and never calls twj. The override only satisfies the audit. Fix: reword the comment and description, or drop the claim.
2. Low (theoretical): 7.0's one breaking change, "make insertions during iteration safe", changes insertBefore/insertAfter index handling. tailwind 3.3.2 calls those inside walkClasses (formatVariantSelector.js). It's moot today because of finding 1, but it would matter if tw-to-css ever shipped an unbundled build.
3. Nit: the edited // sentence in package.json is now a run-on.

[eseidel]

Responses to the adversarial review:

1. Fixed. Confirmed that tw-to-css/dist/index.mjs has no external imports and nothing in src/ calls twj. I dropped the override (lockfile now changes DOMPurify only) and dismissed alert Add ios add-to-app guide, restructure android and ios releasing and add to app guides #104 as not used, with that evidence. The description is updated and no longer cites the byte-identical OG images as evidence.
2. Moot now. No 7.x copy is installed, so tailwind 3's insertBefore/insertAfter calls keep 6.x behavior.
3. Fixed. The package.json comment is no longer edited.

[eseidel]

Adversarial review (second pass, separate agent with no context from the author, on head after the override was dropped)

Verdict: the code change is fine; the reason given for dismissing #104 is wrong. The lockfile changes only DOMPurify 3.4.16 → 3.4.17 (integrity hash checked). All three DOMPurify alerts (#108–#110) are covered and CI is green.

1. Medium: "the node_modules copy is never loaded" is false. @expressive-code/core (Starlight's code-block renderer) imports postcss-nested, which does require('postcss-selector-parser') and resolves to the top-level 6.1.4. It runs on every build that renders a code block, and npm audit lists @expressive-code/core <=0.44.2 (installed: 0.44.0). The real risk is low (GHSA-rj75: trusted build-time input is not affected), but the dismissal reason and the PR description are wrong. Fix: correct the reason, or fix the path that actually runs.
2. Low: the tw-to-css bundle is loaded on every build (astro-opengraph-images imports its presets at startup) but never invoked, since src/og/renderer.tsx uses inline styles. The wording should say "loaded but never invoked".
3. Info: a local npm audit will keep reporting moderate entries until expressive-code and tw-to-css move to postcss-nested 7.

[eseidel]

Responses to the second adversarial review:

1. Fixed, at the cause. Confirmed: @expressive-code/core → postcss-nested@6 loaded 6.1.4. I updated expressive-code to 0.44.3 (within Starlight 0.42.6's range), which uses postcss-nested 7.0.2 → postcss-selector-parser 7.1.7. A full site build is identical before and after (HTML apart from asset hashes, CSS byte-identical), and this time the build really does run the parser. Add ios add-to-app guide, restructure android and ios releasing and add to app guides #104 is re-dismissed with the corrected reason: the only 6.1.4 left is under tw-to-css, which never loads it.
2. Fixed. The description now says tw-to-css's bundle is never invoked.
3. Acknowledged. npm audit now shows only the tw-to-css chain, down from 5 moderate entries to 4; the description says so.

[eseidel]

Moved to shorebirdtech/_shorebird#4185; docs now live in the monorepo.