@next/mdx: Turbopack rule uses `as: '*.tsx'` causing unnecessary double-processing of MDX output

[314systems]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/staging-monad-ns775c

To Reproduce

1. Create a Next.js app with @next/mdx and Turbopack enabled (default in canary).
2. Add a page like app/heavy/page.mdx that uses rehype-katex with several math equations.
3. Run next dev.
4. Observe that compilation of the MDX file takes significantly longer than expected.

The slow path is triggered by as: '*.tsx' in the Turbopack rule inside
packages/next-mdx/index.js, which routes already-compiled JavaScript through
Turbopack's TypeScript/JSX pipeline a second time.

Current vs. Expected behavior

Current:
The Turbopack loader rule for .mdx files sets as: '*.tsx', which tells
Turbopack to re-process the loader output through its full TypeScript/JSX
pipeline (type-stripping → JSX transform → source-map merge).
@mdx-js/mdx already compiles MDX to plain JavaScript using the automatic JSX
runtime (_jsx()/_jsxs() calls). The output contains no JSX syntax and no
TypeScript, so the extra pipeline is pure overhead.
For large outputs (e.g. rehype-katex on a math-heavy page: ~1.9 MB), the
redundant source-map merging alone adds ~50 s of compilation time.

Expected:
The rule should use as: '*.js' so Turbopack treats the loader output as
plain JavaScript and skips the unnecessary TypeScript/JSX pipeline.
The fix is a one-line change:

- as: '*.tsx',
+ as: '*.js',

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.12.1
  npm: 10.5.0
  Yarn: 1.22.19
  pnpm: 8.15.6
Relevant Packages:
  next: 16.2.0-canary.85 // Latest available version is detected (16.2.0-canary.85).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.9.3

Which area(s) are affected? (Select all that apply)

Markdown (MDX)

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

No response

[timneutkens]

The assessment (seemingly written by AI) is wrong. The difference between as: '*.js' and as: '*.tsx' is at most milliseconds

Stuff like this seems pure guessing / hallucination:

the redundant source-map merging alone adds ~50 s of compilation time.

It won't be resolved by changing as.

I had a look at a trace from the provided application and switching to as: '.js' did not help much. It's just a lot of code being generated that then needs to be parsed. Most of the time is spent running the loader.

[314systems]

I previously reached an incorrect conclusion because the issue seemed to be resolved after I changed the file extensions to .js, deleted the .next directory, and restarted the development server.

[314systems]

As a temporary workaround, I resolved the hanging issue by compiling MDX manually.

import { evaluate } from "@mdx-js/mdx";
import * as runtime from "react/jsx-runtime";
import rehypeKatex from "rehype-katex";
import rehypePrettyCode from "rehype-pretty-code";
import remarkGfm from "remark-gfm";
import remarkMath from "remark-math";

export async function compileMdx(source: string) {
  const { default: MDXContent } = await evaluate(source, {
    ...runtime,
    baseUrl: import.meta.url,
    remarkPlugins: [remarkMath, remarkGfm],
    rehypePlugins: [rehypeKatex, rehypePrettyCode],
  });

  return MDXContent;
}