Esbuild: [Feature] UMD bundle support

[jyboudreau]

UMD is used by many libraries to support legacy module systems. Migrating to esbuild is difficult when relying on this format.

There are some workarounds but they have major downsides:

1. Post-process the esbuild IIFE output to add the UMD wrapper if you don't have any external dependencies: Makes sourcemap difficult to deal with and makes builds slower. (#482) would simplify this workaround and solve the source map issue but still not allow external dependencies.
2. Use rollup/webpack's UMD support with esbuild transformers (instead of babel): Doesn't benefit from esbuild's ultra fast dependency resolution and bundling.

Willing to give this a go myself if there is interest to include this feature.

[shrinktofit]

System js, too, please:)

[prantlf]

[UMD] format is similar to the IIFE format. Just the module wrapper and setting the global variable differs. The real "fun" will begin if you want to convert externals to AMD/CJS imports, when you call the factory function in the UMD wrapper. But this is not needed for projects that bundle all their dependencies or use globals to access externals.

I needed just to bundle [local modules without external dependencies]. It is probably the most often case how to simply publish a library in the most interoperable format.

I introduced --format=umd in #513.

[David-Else]

Do we really need these legacy formats? ECMAScript modules were meant to resign them to the dustbin, and now after a ridiculous delay, we finally even have ECMAScript modules in Node LTS with Node 14 and near universal browser support.

The old module formats can safely die now... or will they haunt us forever?

[jyboudreau]

@David-Else I agree with the general sentiment and would love for ESM to have solved the whole module thing once it was supported in browser and node, unfortunately the world is messy. I think that ESM being supported in Node is a great milestone that marks the start of transition towards libraries supporting ESM. It's unfortunately not the end of CommonJS, IIFE or even AMD and far from it.

If you're building an app, I'm sure you will have an easier time with everything being ESM. I think the problems are more apparent when providing libraries.

ESM in Node is not so straightforward. Many supporting libraries don't support it well yet, see Jest for example.

Here is a good article that touches on some of the problems with ESM in Node: https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1

There are also problems with ESM on the browser. Using pure ESM with a huge dependency chain of imports is just not practical for performance reasons.

In the end, UMD is just a way to bundle three formats (CJS, IIFE and AMD) in one and makes it easier to support users. And 2 of those formats are already considered useful enough to be included in esbuild.

Some benefits of UMD for library creators:

• No need to document and provide 3 different file formats of your library to your users.
• No need to explain how to use transpilation to your users if they are on a platform that doesn't support ESM (remember not everybody is using Node 14 or browsers that support ESM).

There are many other arguments to be made here... but hopefully this is enough for now consider that UMD might be a desirable feature in a bundler/transpiler in order for esbuild to be usable by library creators.

[evanw]

FYI the new banner and footer options from #482 are now implemented and have been released. You should be able to implement this feature using those options.