Add importmap option to Bun.build()

[georgpukk]

What is the problem this feature would solve?

Let's say you're developing a browser app. It has two entry points - index.js and worker.js - both of which import many modules so you use Bun.build to bundle them.

But then there are some modules that you don't want to bundle - you want them to remain external - so you add them to the external array.

And then in production you use an import map to resolve these external modules.

But because your browser app has a (module) worker, there's an issue - import maps are not available in workers.

So this is where this proposal comes in.

What is the feature you are proposing to solve the problem?

An importmap option that accepts import map object through which the bundler would map and rewrite module specifiers.

It would act like the currently existing external option but with the added capability to rewrite module specifiers.

If the same module specifier is provided both in external and importmap then the latter takes precedence.

Example usage:

await Bun.build({
	entrypoints: ['./index.js', './worker.js'],
	importmap: {
		imports: {
			three: 'https://cdn.jsdelivr.net/npm/[email protected]/+esm',
			uhtml: 'https://cdn.jsdelivr.net/npm/[email protected]/+esm'
		}
	},
	outdir: './build'
})

What alternatives have you considered?

Use Rollup with rollup-plugin-import-map.

[trusktr]

Standardizing with standard ESM seems very ideal.

If Node's importmap comes out too, then Node, Bun, and Deno would all have the same standardized way for code dependencies to be specified which would be extremely beneficial for everyone.

Just npm install, bun install, or deno install (or in Deno's case just inline URLs in import statements) with one common end result: in any browser, just use the generated importmap.json file and you have working dependencies no matter which backend JS tool you use.

Also see https://wintertc.org/ for cross-runtime standardization.

This would be breathtakingly wonderful.

EDIT: I may have thought about this in the opposite direction these runtimes want: from runtime to browser, whereas the runtimes want to use importmaps for their own dependencies. I think it could go either way: use importmaps for the runtimes, but the tools could also output importmaps for browsers, to make these tool useful for both serverside code and for browser dependency management (most people use npm for browser dependency management for example, regardless if they run a Node server or not)