Skip to content

fix: bundle jsdom v29 CSS assets so the language server starts - #523

Merged
DylanPiercey merged 1 commit into
mainfrom
claude/inspiring-fermat-4hfu3r
Jun 24, 2026
Merged

fix: bundle jsdom v29 CSS assets so the language server starts#523
DylanPiercey merged 1 commit into
mainfrom
claude/inspiring-fermat-4hfu3r

Conversation

@DylanPiercey

@DylanPiercey DylanPiercey commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

jsdom 26 → 29 switched jsdom to a new CSS engine that breaks the esbuild-bundled language server in three ways, crashing it on startup so the VS Code extension failed to activate (Pending response rejected since connection got disposed) — failing CI on main.

Fixed with a small patch-package + esbuild split:

  • jsdom synchronous-XHR worker — located via a top-level require.resolve of an asset esbuild can't bundle. Sync XHR is unused, so a patch removes the feature outright (patches/jsdom+29.1.1.patch).
  • css-tree JSON data — loaded via createRequire(import.meta.url), which resolves against the output bundle once bundled. A patch switches those to static JSON imports (patches/css-tree+3.2.1.patch); works both bundled (esbuild) and unbundled (Node, via with { type: "json" }).
  • jsdom default UA stylesheet — read from a .css asset at load. It's load-bearing (axe relies on getComputedStyle, e.g. the marquee visibility check), so esbuild inlines it at build time, and now throws if the read shape changes so a future jsdom bump fails the build loudly instead of shipping a crashing bundle.

Patches apply via patch-package on postinstall (a stale patch fails the install loudly on the next dep bump).

Verified: the bundled server (dev + minified prod) completes LSP initialize and runs the full jsdom + css-tree + axe path — <img> without alt yields the expected diagnostic, marquee yields none (matching the fixture), and the inlined stylesheet is confirmed in the bundle. The 133 unbundled @marko/language-server tests pass against the patched deps, and build / lint / tsc are clean.

@changeset-bot

changeset-bot Bot commented Jun 24, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 50b38ed

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai

coderabbitai Bot commented Jun 24, 2026

Copy link
Copy Markdown

Review Change Stack

Walkthrough

scripts/marko-esbuild.mts extends two esbuild plugins used when bundling Marko. The jsdom-fix plugin receives two changes: its XMLHttpRequest-impl.js handler is updated to replace the require.resolve('./xhr-sync-worker.js') call with the string "null" via an exact substitution, and a new onLoad handler for computed-style.js reads browser/default-stylesheet.css from disk at build time and inlines its contents by replacing the fs.readFileSync call with JSON.stringify of the CSS. The css-tree-fix plugin gains an onLoad handler for css-tree/lib/data.js, data-patch.js, and version.js that removes the createRequire(import.meta.url) shim, converts require() calls into static ES import statements, and rewrites the version export to reference the statically imported package.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title directly describes the main fix: bundling jsdom v29 CSS assets to resolve language server startup failures.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description check ✅ Passed The pull request description is directly related to the changeset, providing clear technical context about jsdom v29 compatibility issues and the specific esbuild plugin modifications being made.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch claude/inspiring-fermat-4hfu3r

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
scripts/marko-esbuild.mts (1)

85-88: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Fail fast when a patch rewrite does not apply.

These rewrites are intentionally version-specific; if upstream formatting changes, replace(...) can silently no-op and reintroduce startup crashes. Consider asserting each expected pattern matched (or count replacements) and throw a clear build error when it doesn’t.

Also applies to: 130-143

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@scripts/marko-esbuild.mts` around lines 85 - 88, The replace() call on the
file contents in the marko-esbuild.mts script silently fails to match the
pattern 'require.resolve("./xhr-sync-worker.js")' if upstream formatting
changes, causing startup crashes without warning. After calling replace() on the
file contents, verify that the replacement actually occurred by asserting that
the original content contained the expected pattern or by comparing before/after
strings, and throw a clear descriptive build error if the pattern was not found.
Apply this same validation approach to all similar patch rewrite patterns
throughout the file (also affects the similar replace operations around lines
130-143).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@scripts/marko-esbuild.mts`:
- Around line 109-112: In the replace method call within the contents assignment
(around the regex pattern for fs.readFileSync), change the second argument from
the string value JSON.stringify(css) to a function callback that returns
JSON.stringify(css). This ensures the replacement text is treated as a literal
string without interpreting special $ tokens like $&, $1, etc., preventing
potential CSS corruption if the stylesheet contains these characters.

---

Nitpick comments:
In `@scripts/marko-esbuild.mts`:
- Around line 85-88: The replace() call on the file contents in the
marko-esbuild.mts script silently fails to match the pattern
'require.resolve("./xhr-sync-worker.js")' if upstream formatting changes,
causing startup crashes without warning. After calling replace() on the file
contents, verify that the replacement actually occurred by asserting that the
original content contained the expected pattern or by comparing before/after
strings, and throw a clear descriptive build error if the pattern was not found.
Apply this same validation approach to all similar patch rewrite patterns
throughout the file (also affects the similar replace operations around lines
130-143).
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 9609375a-01cb-4c36-a5db-3c32fe6f0a34

📥 Commits

Reviewing files that changed from the base of the PR and between 8570e73 and ff97393.

📒 Files selected for processing (1)
  • scripts/marko-esbuild.mts

Comment thread scripts/marko-esbuild.mts Outdated
@DylanPiercey
DylanPiercey force-pushed the claude/inspiring-fermat-4hfu3r branch from ff97393 to 01a6fd8 Compare June 24, 2026 02:18
jsdom 29's new CSS engine breaks the esbuild-bundled language server in
three ways and crashes it on startup (the VS Code extension failed to
activate with "Pending response rejected since connection got disposed").
Fixed with a small patch-package + esbuild split:

- jsdom locates its synchronous-XHR worker via a top-level require.resolve
  of an asset esbuild can't bundle. Sync XHR is unused, so a patch removes
  the feature outright (patches/jsdom+29.1.1.patch).
- css-tree loads its JSON data via createRequire(import.meta.url), which
  resolves against the output bundle once bundled. A patch switches those
  to static JSON imports (patches/css-tree+3.2.1.patch).
- jsdom reads its default UA stylesheet from a .css asset at load. That
  stylesheet is load-bearing (axe relies on computed styles, e.g. the
  marquee "element is visible" check), so esbuild inlines it at build time
  and now throws if the read shape changes, failing the build loudly.

Patches are applied via patch-package on postinstall.
@DylanPiercey
DylanPiercey force-pushed the claude/inspiring-fermat-4hfu3r branch from 01a6fd8 to 50b38ed Compare June 24, 2026 02:42
@DylanPiercey
DylanPiercey merged commit 31c991b into main Jun 24, 2026
5 checks passed
@DylanPiercey
DylanPiercey deleted the claude/inspiring-fermat-4hfu3r branch June 24, 2026 02:51
@DylanPiercey DylanPiercey moved this to Done in Roadmap Jun 29, 2026
@DylanPiercey DylanPiercey self-assigned this Jun 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant