fix(transforms): compile MDX before parsing its imports (depends on #2999)

[mattboon]

Summary

A .tsx page importing an .mdx component 500'd with a message that sent you looking for a file that was sitting right there:

Component has missing dependencies:
  - @/components/snippet.mdx (from …/pages/test/r-tsx-imports-mdx.tsx):
    Failed to read file: Transform failed with 1 error: <stdin>:1:1: ERROR: Syntax error

The file was found and read. The dependency scan of it failed. parseLocalImports hands source to esbuild to strip types before lexing imports, choosing the loader from the file extension — and .mdx maps to the jsx loader. Markdown prose is not JSX, so esbuild rejected byte one, and the resulting exception was reported as a missing dependency.

That also explains the asymmetry the reproducer noticed — MDX importing MDX works fine, because MDX pages are compiled through the parse stage first; only this dependency-scanning path skipped it.

MDX and Markdown are now compiled to JSX first, exactly as the transform pipeline's parse stage does, and the imports are read out of that. .css and .json already short-circuited above this point; .mdx simply had no equivalent handling.

Reproduction

• Route: r-tsx-imports-mdx.tsx
• Test: src/transforms/esm/import-parser.test.ts (new — this module had no direct coverage)

Test evidence

parses imports from a .tsx file ... ok
parses imports out of an .mdx file instead of failing to lex it ... ok
handles an .mdx file with no imports ... ok
short-circuits .css and .json without invoking the compiler ... ok
ok | 1 passed (4 steps) | 0 failed

The MDX cases register a stub ContentProcessor (the MDX extension is not loaded in unit tests) and assert both that the imports are found and that the content compiler was invoked — so the routing of .mdx away from raw esbuild is what is actually under test.

Wider suite: deno task test:unit → 2525 passed | 0 failed.

SSR evidence

$ curl -so/dev/null -w '%{http_code}' http://localhost:3010/test/r-tsx-imports-mdx
200          # was 500

$ curl -s http://localhost:3010/test/r-tsx-imports-mdx | grep -oE 'Snippet</h2>|piece of MDX|point one'
Snippet</h2>
piece of MDX
point one

The MDX renders inline, which is what the route was written to check.

Client evidence

PASS /test/r-tsx-imports-mdx

All six MDX routes in the matrix (n, o, p, q, r, s) now pass the hydration sweep.

Related

• Bug 7 of the reproducer matrix.

---

Chain: this PR is part of a 13-PR chain fixing the bugs catalogued in
veryfront-router-testing.
Its base is the previous PR in the chain, so the diff shows only this fix.
The root of the chain is #2999 (fix/ssr-lazy-import-graceful-degrade) — merge #2999 first, then
rebase the chain onto main.

Regression gate: deno task test:unit → 2525 passed | 0 failed; deno task lint,
deno task fmt:check and deno task typecheck all clean. The reproducer's full 56-route
matrix (ROUTES.txt + sweep.sh) was re-run after every fix: 7 routes improved, 0 regressed.
A 46-route Chromium hydration sweep (client-sweep.mjs) backs the client-side claims.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6df7b936f3

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Handle server-rewritten MDX imports

When an MDX file imports a project file with a relative specifier, the real content compiler invoked here with the server target rewrites ./Child or ../Child to a file://... specifier before parseSource is lexed. The loop below only records ./, ../, and @/ imports, so those relative MDX dependencies no longer enter parseResult.imports; SSRModuleLoader then skips the recursive transform and cannot rewrite them to cache temp modules, leaving the compiled MDX to import raw project files or miss dependency errors. Please preserve the original specifiers for dependency parsing or normalize file:// imports back to local project paths.

Useful? React with 👍 / 👎.

[kwakayama]

Score: 86/100

Compiling MDX/Markdown before dependency scanning matches the main transform pipeline and fixes the raw-MDX-to-esbuild failure. The targeted tests cover MDX with imports, MDX without imports, TSX, and CSS/JSON short-circuits.

Not merge-ready yet:

• This is stacked on lower open PRs, including blocked/type-failing PRs.
• The PR status rollup only shows CLA, not full CI.

Watch item: import discovery now depends on the full MDX content compiler in this utility path. That is probably the right semantic match, but it increases coupling and runtime cost, so it should remain intentional.

[kwakayama]

Follow-up approval after #2999 merged and the stack was rebased onto main.

Score: 91/100.

Rationale: MDX import compilation ordering is scoped and covered by the rebased stack regression pass.

Next step: merge after lower stack PRs and refreshed checks are green.

The base branch was changed.

[kwakayama]

Approval after rebasing onto current main and removing sanitizer opt-outs from the import-parser regression test.

Score: 92/100.

Real bug: raw .mdx is not JSX, so parsing it directly through the JSX/esbuild path can fail before dependency analysis sees the imports. The fix compiles MDX first and then parses the compiled module, including server-rewritten file:// imports for relative components and CSS.

Quality note: the test now keeps Deno leak checks enabled and stops the shared esbuild service instead of raising the sanitizer baseline.

Verification:

• deno test --allow-all src/transforms/esm/import-parser.test.ts
• deno task lint:sanitizer-baseline
• deno task lint
• deno test --allow-all src/transforms/esm/import-parser.test.ts src/transforms/esm/specifier-resolver.test.ts src/rendering/orchestrator/module-loader/esm-rewriter.test.ts

Next step: wait for refreshed GitHub checks, then merge when green.