chore(deps): bump dompurify → 3.4.11 + astro → 6.4.6 (vite 6.4.3 dropped — breaks e2e)#1394
Merged
Conversation
Bumps [dompurify](https://github.com/cure53/DOMPurify) from 3.4.8 to 3.4.9. - [Release notes](https://github.com/cure53/DOMPurify/releases) - [Commits](cure53/DOMPurify@3.4.8...3.4.9) --- updated-dependencies: - dependency-name: dompurify dependency-version: 3.4.9 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 6.4.2 to 6.4.3. - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/v6.4.3/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v6.4.3/packages/vite) --- updated-dependencies: - dependency-name: vite dependency-version: 6.4.3 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [astro](https://github.com/withastro/astro/tree/HEAD/packages/astro) from 6.1.10 to 6.4.6. - [Release notes](https://github.com/withastro/astro/releases) - [Changelog](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md) - [Commits](https://github.com/withastro/astro/commits/astro@6.4.6/packages/astro) --- updated-dependencies: - dependency-name: astro dependency-version: 6.4.6 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
…y-3.4.9' into deps/merge-vite-dompurify-astro
…astro-6.4.6' into deps/merge-vite-dompurify-astro
vite 6.4.3's client bundle deterministically trips the render_recovery e2e test on x86_64-linux (master green, branch 4/4 fail, darwin green) — an extra xterm paint slips through the stalled-render-loop window. Pin vite back to 6.4.2 and keep only the dompurify (→3.4.11) + astro bumps. Root pnpmDeps hash regenerated for the vite-free lockfile. See #1394 discussion; vite 6.4.3 ↔ render_recovery to be tracked separately.
srid
changed the title
Member
Author
🧪 CI metrics — leased pool boxThe x86_64-linux lane ran on
Pool status (8 boxes)
Posted by |
srid
added a commit
that referenced
this pull request
Jun 18, 2026
…3 still excluded (#1397) Consolidates the remaining open Dependabot bumps into one PR — a single CI run and one regenerated Nix pnpm-deps hash, the same pattern as #1394. ## Bumps | PR | Package | From → To | Scope | Status | |----|---------|-----------|-------|--------| | #1396 | `ws` | 8.20.1 → **8.21.0** | root workspace (`server` + surface examples) | ✅ included | | #1395 | `astro` | 6.1.10 → **6.4.8** (`^6.4.6`) | `docs/atlas` (standalone) | ✅ included | | #1393 | `vite` (dev) | 6.4.2 → 6.4.3 | root workspace | ❌ **excluded** | ## Why vite 6.4.3 is still excluded #1394 dropped vite 6.4.3 because its client bundle **deterministically breaks** the `render_recovery` e2e scenario ("Regaining window focus repaints a render-stalled terminal", #1381) on **x86_64-linux** — failed 4/4 attempts on a warm CI box; darwin passes. That interaction is still unresolved, so vite stays pinned at 6.4.2. #1393 should be re-attempted only once the vite ↔ `render_recovery` interaction is fixed. ## Nix hash - `ws` touches the root workspace lockfile. The surface examples (`base.nix` and friends) reuse the root `pnpmDeps`, so **only the root `default.nix` `fetchPnpmDeps` hash changed**: `sha256-7damxI1mQ2xbZpDO5NvE8mmPGjyAuck3nybEBsaDUT4=`. - Regenerated by forcing a re-fetch (the FOD won't re-run on an unchanged declared hash); full `nix build .#default` is green afterward. - `website/default.nix` is untouched (its astro was already bumped in #1394). ## docs/atlas `docs/atlas` is a standalone project — its own `pnpm-lock.yaml`, **no `default.nix`** (not Nix-built). Its lockfile was regenerated and `docs/atlas/dist/` rebuilt + committed (the only delta is the `<meta generator>` string moving `Astro v6.4.3` → `v6.4.8` across all 41 pages) so the `ci::atlas-sync` gate stays green. Closes #1396 Closes #1395 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Consolidates Dependabot dependency bumps into a single PR sharing one CI run and one set of regenerated Nix pnpm-deps hashes.
Bumps
dompurifyastro^6.4.6)/websitevite(dev)Why vite 6.4.3 was dropped
vite 6.4.3's client bundle deterministically breaks the
render_recoverye2e scenario ("Regaining window focus repaints a render-stalled terminal", added in #1381) on x86_64-linux:render_recoveryfailed 4/4 attempts on the same warm CI boxThe test asserts zero xterm paints while the render loop is stalled; under vite 6.4.3 an extra paint slips through, tripping the assertion before it even verifies the focus-repaint behavior. Bisected to vite as the sole client-affecting change (lockfile delta was only vite + dompurify). vite is pinned back to 6.4.2 here; the 6.4.3 ↔
render_recoveryinteraction should be tracked and resolved separately before re-attempting that bump.Notes
website/package.json; its lockfile was stale, sowebsite/pnpm-lock.yamlwas regenerated (astro resolves to 6.4.7 within^6.4.6).^3.4.9range — supersedes the 3.4.9 security fix).fetchPnpmDepshashes regenerated and verified deterministic vianix build --rebuild:default.nix→sha256-YaxrK53rfL5nWhS29No4PqG4FOvKQXfDdUFhfgNqb/c=website/default.nix→sha256-RxMbH3KNdnrO050cp+nQm1TKcPAThPL+q5pmPBfxFiw=Closes #1392
Closes #1390
🤖 Generated with Claude Code