plugin-formatjs: SWC plugin crashes with Next.js 16.2.1 + React Compiler + @swc/plugin-formatjs

[meltuhamy]

Describe the bug
Fresh next js + react compiler + @swc/plugin-formatjs build breaks with a build error.

URL to minimal reproduction
https://github.com/meltuhamy/next-swc-formatjs-reactcompiler-bug

1. Start a fresh next app (npx create-next-app@latest) and when prompted turn on React Compiler (or just use this repo)
2. npm install @swc/plugin-formatjs react-intl
3. Add reactCompiler: true, output: 'export' and experimental: { swcPlugins: [["@swc/plugin-formatjs", { ast: true }]]} to the next config.
4. Update page.tsx to use several translated messages (note: it will work with 1 or 2 translated strings, but starts breaking with more messages). I've included an example page.tsx below.
5. Run npm run build

Example page.tsx:

"use client";
import { useIntl, IntlProvider } from "react-intl";

function Messages() {
  const intl = useIntl();
  return (
    <ul>
      <li>{intl.formatMessage({ id: "a", defaultMessage: "Message A" })}</li>
      <li>{intl.formatMessage({ id: "b", defaultMessage: "Message B" })}</li>
      <li>{intl.formatMessage({ id: "c", defaultMessage: "Message C" })}</li>
      <li>{intl.formatMessage({ id: "d", defaultMessage: "Message D" })}</li>
      <li>{intl.formatMessage({ id: "e", defaultMessage: "Message E" })}</li>
    </ul>
  );
}

export default function Page() {
  return (
    <IntlProvider locale="en" messages={{}}>
      <Messages />
    </IntlProvider>
  );
}

Expected behavior
The build should succeed without errors.

Actual behaviour
The build fails with the output below

npm run build

> next-swc-formatjs-reactcompiler-bug@0.1.0 build
> next build

▲ Next.js 16.2.1 (Turbopack)
- Experiments (use with caution):
  · swcPlugins

  Creating an optimized production build ...

thread '<unnamed>' panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/swc_common-19.0.0/src/syntax_pos/hygiene.rs:425:14:
Should able to deserialize: failed to deserialize `swc_common::syntax_pos::hygiene::MutableMarkContext`

Caused by:
    Eof { name: "u32", expect: Small(1) }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

> Build error occurred
Error: Turbopack build failed with 1 errors:
./src/app/page.tsx
Failed to execute SWC plugin
An unexpected error occurred when executing an SWC EcmaScript transform plugin.
This might be due to a version mismatch between the plugin and Next.js. https://plugins.swc.rs/ can help you find the correct plugin version to use.

Failed to execute @swc/plugin-formatjs

Caused by:
    0: failed to run Wasm plugin transform. Please ensure the version of `swc_core` used by the plugin is compatible with the host runtime. See the documentation for compatibility information. If you are an author of the plugin, please update `swc_core` to the compatible version.

                Note that if you want to use the os features like filesystem, you need to use `wasi`. Wasm itself does not have concept of filesystem.

                https://swc.rs/docs/plugin/selecting-swc-core

                See https://plugins.swc.rs/versions/from-plugin-runner/24.0.0 for the list of the compatible versions.

                Build info:
                    Date: 2026-03-18
                    Timestamp: 2026-03-18T00:21:41.521826000Z

                Version info:
                    swc_plugin_runner: 24.0.0
                    Dependencies: anyhow 1.0.100,blake3 1.5.4,parking_lot 0.12.3,rustc-hash 2.1.1,serde 1.0.228,serde_json 1.0.140,swc_atoms 9.0.0,swc_common 18.0.1,swc_plugin_proxy 20.0.0,swc_transform_common 12.0.0,tracing 0.1.41,vergen 9.0.0
                
    1: RuntimeError: unreachable

Import traces:
  Client Component Browser:
    ./src/app/page.tsx [Client Component Browser]
    ./src/app/page.tsx [Server Component]

  Client Component SSR:
    ./src/app/page.tsx [Client Component SSR]
    ./src/app/page.tsx [Server Component]


    at ignore-listed frames

Additional context

None

[kdy1]

@claude Try to fix this. If it's an issue of the core runtime, report it to https://github.com/swc-project/swc repository

[claude]

Claude finished @kdy1's task in 20m 50s —— View job

---

Analysis of plugin-formatjs crash with Next.js 16.2.1

Tasks

• Gather context (issue details, plugin source)
• Analyze error — version mismatch vs. runtime bug
• Inspect swc_common/src/syntax_pos/hygiene.rs proxy functions
• Identify and confirm root cause
• Determine fix location and report

---

Root Cause: Buffer Overflow Bug in swc_common WASM Plugin Proxy

This is not a version mismatch and not a bug in the formatjs plugin itself. It is a pre-existing buffer overflow in swc_common's WASM plugin host/guest IPC mechanism that gets triggered by the combination of React Compiler + multiple intl.formatMessage() calls.

The Buggy Pattern (confirmed in source)

Three functions in swc_common/src/syntax_pos/hygiene.rs allocate a return buffer by serializing MutableMarkContext(0, 0, 0):

// SyntaxContext::remove_mark (line ~406), Mark::is_descendant_of, Mark::least_ancestor
let serialized = PluginSerializedBytes::try_serialize(
    &VersionedSerializable::new(MutableMarkContext(0, 0, 0)),  // ← only 4 bytes in CBOR
).expect("...");
let (ptr, len) = serialized.as_ptr();  // len = 4

unsafe { __syntax_context_remove_mark_proxy(self.0, ptr as _); }
// ↑ Host writes result into ptr — but may write MORE than `len` bytes!

let context: MutableMarkContext =
    PluginSerializedBytes::from_raw_ptr(ptr, len)  // ← STILL uses original len=4
        .deserialize()
        .expect("Should able to deserialize");  // ← PANICS with Eof when result > 4 bytes

Why It Panics at Exactly Eof { name: "u32", expect: Small(1) }

CBOR (used for plugin serialization since swc_common 17.0.0) uses variable-length integer encoding:

• Values 0–23 → 1 byte
• Values 24–255 → 2 bytes

So MutableMarkContext(0, 0, 0) = 4 bytes (83 00 00 00), but MutableMarkContext(24, 0, 1) = 5 bytes (83 18 18 00 01).

Tracing through a remove_mark call with mark value 24:

Bytes read	Content	Remaining needed
83	array header (3 items)	—
18 18	1st u32 = 24	—
00	2nd u32 = 0	—
EOF	← only 4 bytes available	3rd u32 = 1 more byte

Result: Eof { name: "u32", expect: Small(1) } — exactly the reported panic.

Why It Manifests With React Compiler + 5+ Messages

React Compiler creates many marks during its AST transformations. By the time @swc/plugin-formatjs runs, the host's mark counter has already incremented past 23. When the plugin's Evaluator visits the transformed AST and calls mark operations (via eval() / eval_tpl()), the proxy returns MutableMarkContext with values ≥ 24. With 1–2 messages the threshold may not be reached; with 5+ it reliably is.

---

The Fix (must go in swc_common)

The fix is to pre-allocate the maximum possible CBOR buffer for MutableMarkContext(u32, u32, u32) (16 bytes) instead of the minimum (4 bytes). All three functions need the same change:

// Before (buggy — only allocates 4 bytes):
let serialized = PluginSerializedBytes::try_serialize(
    &VersionedSerializable::new(MutableMarkContext(0, 0, 0)),
)...

// After (fixed — allocates 16 bytes, sufficient for all u32 values):
let serialized = PluginSerializedBytes::try_serialize(
    &VersionedSerializable::new(MutableMarkContext(u32::MAX, u32::MAX, u32::MAX)),
)...

Apply to: SyntaxContext::remove_mark, Mark::is_descendant_of, Mark::least_ancestor in swc_common/src/syntax_pos/hygiene.rs.

---

Conclusion

This cannot be fixed in this repository — the bug is in the swc_common core runtime. Please report this to swc-project/swc with:

• Title: [swc_common] WASM plugin proxy buffer overflow in hygiene.rs when MutableMarkContext field values ≥ 24
• Affected functions: SyntaxContext::remove_mark, Mark::is_descendant_of, Mark::least_ancestor
• Reproduction: Next.js 16.2.1 + React Compiler + @swc/plugin-formatjs with 5+ intl.formatMessage() calls
• Root cause: CBOR variable-length encoding causes the pre-allocated 4-byte buffer to be too small when any field value ≥ 24
• Fix: use MutableMarkContext(u32::MAX, u32::MAX, u32::MAX) for pre-allocation

[meltuhamy]

Hi @kdy1 , btw I realised it is not just related to react compiler. It seems to crash even when reactCompiler: false.

See an even simpler setup here: https://github.com/meltuhamy/next-swc-formatjs-reactcompiler-bug/tree/simpler

Summary:

Minimal reproduction

src/app/page.tsx -- 24 lines, no react-intl imports, no formatjs API usage:

"use client";

let config: { info: { x: string } | null } = { info: null };

export function setConfig(c: typeof config) {
  config = c;
}

function getParams() {
  const p: { x?: string } = {};
  if (config.info) {
    p.x = config.info.x;
  }
  return p;
}

function run() {
  console.log(getParams());
}

export default function Page() {
  return <div onClick={() => run()}>click</div>;
}

What triggers it

The crash requires all four of these together:

1. A let variable with a nullable nested object type ({ info: { x: string } | null })
2. An exported function using typeof on that variable (c: typeof config)
3. A function that builds an object with an optional property type ({ x?: string }) and conditionally assigns from the nullable field
4. JSX (a React component in the same file)

Removing any one of these makes the build succeed. The file doesn't use any formatjs/react-intl APIs -- the plugin crashes just from processing the TypeScript AST.

reactCompiler: true lowers the threshold further

With reactCompiler: true, the crash threshold drops -- even 4 simple intl.formatMessage() calls in a single component trigger the same panic. With reactCompiler: false, simple intl.formatMessage() calls work fine (tested up to 50), but the nullable-type pattern above still crashes.

[kdy1]

It looks like a separate issue. Can you file another one?