Build in parallel

[fregante]

Here's what I'm trying to do: Multiple entry, multiple output.

{
	input:[
		'a.ts', // output/a.js
		'b.ts', // output/b.js
	],
	output: {
		dir: 'output',
		format: 'iife', // Error: Not supported
	}
}

No overlaps. Just 2 unrelated entry points processed in parallel.

Unfortunately that config causes this error:

[!] Error: UMD and IIFE output formats are not supported for code-splitting builds.

---

Webpack can do this with:

{
	entry: {
		'bundle-a': './a',
		'bundle-b': './b',
	},
	output: {
		path: path.join(__dirname, 'distribution'),
		filename: '[name].js'
	}
}

For my app, Webpack does this (and a few more transforms) in 9 seconds.

Rollup on the other hand handles this in series in ~7 seconds per each file (4 files) using this config:

export default [
	'a.ts',
	'b.ts',
	// 4 files
].map(input => ({
	input,
	output: {
		dir: 'output',
		format: 'iife',
	},
	...
}));

Feature Use Case

I have a web extension with multiple, separate entry points. Both Webpack and Parcel let me specify multiple files.

Feature Proposal

• Either support IIFE with the entry array, or
• Process config arrays (export default [], Support for multiple bundles specified in a single config #863) in parallel, with multiple threads

[lukastaegert]

So Rollup supports this but is too slow. There already are issues about this and this one does not add anything new. Supporting what you want is a major refactoring with lots of potential side-effects in the plugin area.

[fregante]

I suppose you're referring to this #3325 (comment)

I get it that Rollup tries to be a plain ESM bundler with "everything else is a plugin" mentality, but it's hard to suggest:

just call the API multiple times

... when Webpack and Parcel do these things out of the box. Especially because those suggestions are followed by:

Mind you, it will not work with watch mode very well 😜

Even with the API, true concurrency is not possible unless you start venturing into workers.

---

Over the years I saw a few long-standing issues being resolved (like the very support of multiple builds in one run: #1389), but sadly every time I try moving to Rollup, I can't (unless I do something very basic).

[lukastaegert]

Multi-threading is also very hard as the plugins need to live in the main thread, so a lot of data needs to be pushed back and forth. The tree-shaking algorithm is also not very multi-threading friendly. That does not mean it is not considered for some things.

[zhaoyao91]

Hi, why was the issue closed? Today this is still a issue. I use rollup to build multiple inputs with multiple configs (cross product). I can exports an array in rollup config, but they only get built one by one, very slow.

[ThePrimeagen]

Yes, I am still having problems with this.

My current solution is to have a script that spawns rollup comamnds with parameters passed in to the location of the generated config. Config is generated and pasted into my /tmp folder.

it really sucks.

[cristian-eriomenco]

Multi-threading is also very hard as the plugins need to live in the main thread, so a lot of data needs to be pushed back and forth. The tree-shaking algorithm is also not very multi-threading friendly. That does not mean it is not considered for some things.

What is the difference between running these (non overlapping srcs) manually in parallel:

npm run rollup:build:components
npm run rollup:build:utils
npm run rollup:build:extensions
npm run rollup:build:logging

vs rollup handling this internally when exporting rollup.config.js:

export default [
...componentsConfig,
...utilsConfig,
...extensionsConfig,
...loggingConfig
]

?