feat(babel): add parallel processing via worker threads by davidtaylorhq · Pull Request #1956 · rollup/plugins

davidtaylorhq · 2026-01-12T19:56:22Z

Rollup Plugin Name: `@rollup/plugin-babel`

This PR contains:

Are tests included?

yes (bugfixes and features will not be merged without tests)
no

Breaking Changes?

yes (breaking changes will not be merged unless absolutely necessary)
no

If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.

List any relevant issue numbers: n/a

Description

feat(babel): add parallel processing via worker threads

Add a parallel option that processes files concurrently using Node.js worker threads. This reduces build times for large projects where Babel transformation is a bottleneck. This is similar to the existing parallel behavior of @rollup/plugin-terser.

This required some fairly significant refactoring, because we can only pass serializable objects between the main thread and the worker threads. It also required changes to the plugin's own build config, so that we can generate a dedicated worker entrypoint.

Validations are added to ensure that unserializable config (e.g. inline babel plugins) cannot be used alongside the new parallel mode. For people using dedicated babel config files, this isn't a problem, because they are loaded directly by babel in the worker thread itself.

The worker threads do have a setup cost, so this only makes sense for large projects. In Discourse, enabling this parallel mode cuts our overall vite (rolldown) build time by about 45% (from ~11s to ~6s) on my machine.

This PR is based on #1954, which should ideally be merged first. Happy to rebase this one on main if the other PR isn't mergable.

For testing, I've pushed a built version of this branch to https://github.com/davidtaylorhq/plugins/tree/babel-parallel-built. In pnpm, it can be installed like:

"@rollup/plugin-babel": "davidtaylorhq/rollup-plugins#babel-parallel-built&path:/packages/babel",

davidtaylorhq · 2026-02-05T15:08:38Z

@Andarist @shellscape sorry for the ping, but just wanted to check if this is something you'd consider looking at? The performance benefits are pretty massive for large projects using Babel.

NullVoxPopuli · 2026-02-09T15:49:59Z

I'm really looking forward to this landing! I have a local tarball that I've been copying into my projects to have the benefits of this PR - and it's really good. I can no longer imagine using babel in rollup/vite/rolldown without the parallel mode <3

(usage without parallel mode is painfully slow)

Andarist · 2026-02-09T17:38:02Z

packages/babel/src/index.js

+
+      const parallelWorkerCount = typeof parallel === 'number' ? parallel : 4;
+      workerPool = new WorkerPool(
+        new URL('./worker.js', import.meta.url).pathname,


is this compatible with repo-wide supported node.js version?

Would ci tell us?

Worker Threads and import.meta.url are both supported in Node 14 👍

Andarist · 2026-02-09T17:39:12Z

packages/babel/src/workerPool.js

have you considered using some existing worker pool libraries?

I aimed to match the implementation of the existing Terser plugin, since I wasn't sure if adding new dependencies would be welcome. I'm certainly happy to explore it though! Did you have any particular libraries in mind?

workerpool looks like it could be a good bet 👀

I guess it's fine to keep it as-is if it matches the one in the terser plugin. It would be nice to extract this to a shared package but I don't know what's the proper drill for this. It probably could/should be extracted once this PR lands.

I investigated this some more, and I do think that switching to the workerpool package is a good idea. It handles a lot more edge cases than the custom implementation, and is much less code.

I've pushed a refactor to use this. But if there are any concerns about introducing a new dependency, let me know and I can revert back to the custom implementation.

shellscape · 2026-02-16T03:36:14Z

@CharlieHelps please do a thorough review of this PR to determine if it's ready to merge. Look at the diff, reviews, comments, and referenced issues/docs/links to build a complete understanding. Then respond with a comment that includes a list of MUST fix items that must be fixed before the the PR is merged, and a list of IMPROVEMENTS that shouldn't block the merge but may be quick improvements or things that could be addressed in a follow up PR. The MUST fix items should explain exactly what's wrong and what needs to change to resolve the problem. Both should be numbered lists and the IMPROVEMENTS list should continue counting up from the MUST list. It's OK if there are no IMPROVEMENTS or MUST fix items, you can just omit the lists.

shellscape · 2026-02-16T03:40:38Z

@davidtaylorhq looks like Github's buggy UX bit us on this and I can't see/approve the CI runs. please push a new commit to the branch to trigger that UX again.

NullVoxPopuli · 2026-02-16T03:48:16Z

@shellscape you can close and re-open a PR to trigger that, usually -- no reason to make a contributor do a silly because GH is buggy <3

charliecreates · 2026-02-16T03:49:34Z

I pulled the branch and reviewed the diff + existing review comments. Local verification for @rollup/plugin-babel (build, test, test:ts) passed; only a no-console eslint warning is present in workerPool.terminate().

MUST fix

Windows/URL-safe worker entry resolution: In packages/babel/src/index.js the worker path is built via new URL('./worker.js', import.meta.url).pathname. .pathname can be Windows-unsafe (e.g. leading /C:/...) and can be URL-encoded. Please switch to either passing the URL directly (new URL('./worker.js', import.meta.url)) or fileURLToPath(new URL('./worker.js', import.meta.url)), and keep WorkerPool compatible.
Fix filter typing: packages/babel/types/index.d.ts currently declares filter?: (id: string, code: string) => Promise<boolean>; but the implementation supports sync filters too. Change this to boolean | Promise<boolean> so TS users aren’t forced async.
Validate numeric parallel values: const parallelWorkerCount = typeof parallel === 'number' ? parallel : 4; accepts 0, negatives, NaN, and floats. Some of these can yield a pool that never creates workers and transforms that never resolve. Please guard with something like Number.isInteger(parallel) && parallel > 0 and throw a clear error otherwise.
Confirm the Rollup support change is intentional: This PR’s commits drop Rollup ^1.20.0 from peerDependencies (now ^2 || ^3 || ^4). If that’s intentional, it should be explicitly called out (and semver/release notes aligned). If it’s not intended as part of this PR, please revert that portion (or split it out).
CI signal before merge: gh pr checks 1956 currently shows “no checks reported”. Please rebase/push or have a maintainer trigger workflows so the PR has a visible CI pass before merging.

IMPROVEMENTS

Remove/avoid console.error in library code: packages/babel/src/workerPool.js logs on terminate failure (console.error('Error terminating worker:', err)) and triggers no-console. Consider swallowing termination errors, or surfacing them via rejected promises instead of logging.
Defensive postMessage error handling: worker.postMessage(task.opts) can throw synchronously (e.g. DataCloneError) if something slips past the serializability guard. Wrapping this in try/catch and rejecting with a targeted “non-serializable babel options in parallel mode” error would make failures much clearer.
Default worker count rationale: Not blocking, but it’d be good to either document why the default is 4 or consider a CPU-based default (with a cap).
Resolve/close review threads: There are still unresolved threads (Node compat / worker-pool library discussion). Not strictly code-blocking, but cleaning those up will make merge readiness clearer.

packages/babel/rollup.config.mjs

packages/babel/package.json

packages/babel/types/index.d.ts

packages/babel/src/transformCode.js

Andarist · 2026-02-16T14:20:56Z

packages/babel/src/transformCode.js

+  transformOptions =
+    babelHelpers === BUNDLED
+      ? addBabelPlugin(transformOptions, bundledHelpersPlugin)
+      : transformOptions;


Hm, so this now relies on babelHelpers input to skip the addBabelPlugin call in the renderChunk's case, right?

Yes that's right - the output plugin doesn't pass babelHelpers 👍

packages/babel/src/index.js

Andarist · 2026-02-16T14:26:56Z

packages/babel/src/index.js

+            return workerPool.runTask({
+              inputCode: code,
+              babelOptions: { ...babelOptions, filename },
+              runPreflightCheck: !skipPreflightCheck,
+              babelHelpers
+            });


q: I'm not sure what we actually get from this.error but maybe it's worth rechecking if we shouldn't "convert" the errors from this to this.error calls?

Yeah I think that makes sense - that'll make things consistent in parallel/non-parallel mode. Done 👍

Andarist · 2026-02-16T14:29:04Z

packages/babel/src/index.js

+    if (parallel) {
+      const parallelAllowed =
+        isSerializable(babelOptions) && !overrides?.config && !overrides?.result;


perhaps it would be nice to move this validation to unpackInputPluginOptions? It would also be quite great if the thrown error message could mention the offending option.

It's tricky to move it entirely to unpackInputPluginOptions, because at that point the 'overrides/customCallback' functions haven't been evaluated, and so we don't have the final babelOptions.

I have improved the error message to give a better indication of which option has failed the serializability check 👍

Andarist · 2026-02-16T14:29:35Z

packages/babel/src/index.js

        }

-        return transformCode(code, babelOptions, overrides, customOptions, this);
+        return transformCode({


q: why we don't attempt to parallelize this one?

Refactored so that the parallel option is available for the output plugin as well 👍

Andarist · 2026-03-16T11:43:32Z

@davidtaylorhq please ping me for a review explicitly when you wrap up the work here and undraft it. I'll try not to miss it

davidtaylorhq · 2026-03-16T15:07:50Z

@Andarist I think this is in a good spot now. I've worked through all of the human & machine comments above, and I've refactored it to use the workerpool package instead of a bespoke implementation. Let me know if you have any further questions/suggestions!

I've updated the babel-parallel-built branch on my fork in case anyone wants to test the latest version against their apps (cc @NullVoxPopuli @mansona)

"@rollup/plugin-babel": "davidtaylorhq/rollup-plugins#babel-parallel-built&path:/packages/babel",

Andarist · 2026-03-17T09:22:48Z

packages/babel/src/index.js

+    );
+  }
+
+  return workerPool.exec('transform', [taskOpts]).catch((err) => context.error(err.message));


q: does context.error actually throws/fails the execution or does it only log the error? I hope it's the first one

Correct - it fails the build. See https://rollupjs.org/plugin-development/#this-error

Structurally equivalent to this.warn, except that it will also abort the bundling process with an error.

Andarist · 2026-03-17T09:25:01Z

packages/babel/src/index.js

+  });
+}
+
+function executeWithWorkerPool(workerPool, context, taskOpts, babelOptions) {


the name of this suggests it's a generic helper for executing different tasks but actually it's only capable of calling transform. I think the name of this helper should reflect that. Please just rename this to transformWithWorkerPool and then taskOpts should become transformsOpts too

Andarist · 2026-03-17T09:25:53Z

packages/babel/src/index.js

+        if (workerPool) {
+          await workerPool.terminate();
        }


nit: this could be await workerPool?.terminate()

Andarist · 2026-03-17T09:26:21Z

packages/babel/src/index.js

+        if (workerPool && !this.meta.watchMode) {
+          await workerPool.terminate();
+        }


nit: similarly here this could be simplified

Suggested change

if (workerPool && !this.meta.watchMode) {

await workerPool.terminate();

}

if (!this.meta.watchMode) {

await workerPool?.terminate();

}

Add a `parallel` option that processes files concurrently using Node.js worker threads. This reduces build times for large projects where Babel transformation is a bottleneck. This is similar to the existing parallel behavior of `@rollup/plugin-terser`, but uses the `workerpool` package instead of a custom implementation. This required some fairly significant refactoring, because we can only pass serializable objects between the main thread and the worker threads. It also required changes to the plugin's own build config, so that we can generate a dedicated worker entrypoint. Validations are added to ensure that unserializable config (e.g. inline babel plugins) cannot be used alongside the new parallel mode. For people using dedicated babel config files, this isn't a problem, because they are loaded directly by babel in the worker thread itself. The worker threads do have a setup cost, so this only makes sense for large projects. In Discourse, enabling this parallel mode cuts our overall vite (rolldown) build time by about 45% (from ~11s to ~6s) on my machine.

davidtaylorhq requested a review from Andarist as a code owner January 12, 2026 19:56

Andarist reviewed Feb 9, 2026

View reviewed changes