feat(babel): add parallel option to transform in worker threads

[NullVoxPopuli-ai-agent]

Note

I am an AI bot: Claude Code, with the Claude Opus 5.5 model. @NullVoxPopuli asked me to open this PR. @NullVoxPopuli, please review.

Adds a parallel option to @rolldown/plugin-babel. With it, the plugin runs Babel in worker threads. This is a port of the same option from @rollup/plugin-babel (rollup/plugins#1956).

babel({
  parallel: true, // or a worker count
  plugins: [['@babel/plugin-proposal-decorators', { version: '2023-11' }]],
})

Behavior

• true starts one worker per CPU core, with a maximum of 4. A number sets the worker count.
• The pool starts on the first transform. It stops in closeBundle (not in watch mode) or closeWatcher.
• Babel options must be structured-cloneable. If a plugin or preset is a function, the first transform fails with an error that names the option, for example overrides[0].presets[0].
• The rolldown part of a Rolldown Babel preset stays in the main thread. So its filters and hooks can still be functions.
• Babel errors from a worker keep loc, so Rolldown still reports foo.js:1:13. The structured clone of an error drops loc, so the worker sends the error as a plain object.

The other recent performance change in @rollup/plugin-babel (rollup/plugins#1954, hook filters) already exists in this plugin.

Benchmark

packages/babel/benchmark compares parallel: false and parallel: true on 100 generated modules with decorators. Run pnpm bench --reporter=verbose in that directory. On an 8-core machine, with 10 samples:

parallel	mean build time
false	3.55 s
true (4 workers)	1.64 s

Pool packages

Build time with each pool package, 4 workers, 12 rounds with a rotated order:

pool	30 modules	300 modules
none (parallel: false)	1.29 s	9.81 s
workerpool	0.89 s	3.61 s
tinypool	0.90 s	3.57 s
artichokie	0.90 s	3.65 s

The differences between the pools are inside the noise (standard deviation 0.01 to 0.08 s), so the plugin uses artichokie, the smallest package.

Notes for review

• New runtime dependency: artichokie@^0.4.5.
• artichokie stop() calls unref() on the workers and does not terminate them. A process that runs many builds keeps the idle workers until it exits.
• Errors from loadOptionsAsync now also get the [BabelError] prefix, because they are now inside the same try block as the transform.
• The test build() helper now calls bundle.close(), so that worker pools stop.
• Not tested: the Vite dev server. The Rolldown builds and the existing Vite build tests pass.

🤖 Generated with Claude Code

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	artichokie@​0.4.5

View full report

[NullVoxPopuli]

seems good to me

[NullVoxPopuli]

idk if there is a better way to do this, but the purpose of doing this much work to see if a config is serializable is to provide a better error to consumers when part of their config is not serializable

[sapphi-red]

Would you add packages/babel/benchmark that compares parallel: false and parallel: true?

Also would you compare the performance with the following packages?

• workerpool
• tinypool
• artichokie

If the performance is same, I'd prefer the one on the bottom in the list as it has smaller package size.

[sapphi-red]

Could we use structuredClone? It has the overhead of actually cloning the vaules, but I think that can be solved by running the check after sending the message was errored.

[NullVoxPopuli-ai-agent]

Done in d7fb6dc. isCloneable is now a structuredClone call in a try block.

The check runs only after a worker message fails with a DataCloneError. The error then names the option, for example "overrides[0].presets[0]" cannot be sent to a worker thread.

(AI reply: Claude Code for @NullVoxPopuli)

[NullVoxPopuli-ai-agent]

Both are done.

packages/babel/benchmark (3eff276) compares parallel: false and parallel: true on 100 generated modules with decorators. Result on 8 cores, 10 samples: 3.55 s against 1.64 s.

Pool comparison, 4 workers, mean build time of 12 rounds with a rotated order:

pool	30 modules	300 modules
none (parallel: false)	1.29 s	9.81 s
workerpool	0.89 s	3.61 s
tinypool	0.90 s	3.57 s
artichokie	0.90 s	3.65 s

The pools are equal inside the noise (standard deviation 0.01 to 0.08 s), so the plugin now uses artichokie (d7fb6dc).

Two notes on artichokie:

• stop() calls unref() on the workers and does not terminate them. A process that runs many builds keeps the idle workers until it exits.
• vitest bench shows the result table only with --reporter=verbose. The other benchmarks in this repo have the same behavior.

(AI reply: Claude Code for @NullVoxPopuli)