add esbuild bundler

[osdevisnot]

This PR adds esbuild bundler with 3 tests for now. I will wait for feedback here or on #232 before adding more tests.

Checklist of Tests

• importing-modules/es-modules
• importing-modules/commonjs
• importing-modules/node-modules
• hashing/asset-cascade
• hashing/avoid-cascade
• hashing/avoid-hash
• hashing/basic-js
• hashing/hash-ignores-parent-dirs
• hashing/hash-on-final-content
• hashing/js-entry-cascade
• hashing/js-import-cascade
• output-module-formats/commonjs
• output-module-formats/custom-browser
• output-module-formats/es-modules
• non-js-resources/custom
• non-js-resources/entry
• non-js-resources/service-worker
• transformations/brotli
• transformations/compress-images
• transformations/compress-svg
• transformations/dead-code
• transformations/dead-code-dynamic
• transformations/flags
• transformations/minify-js
• transformations/transpile-js
• code-splitting/between-new-worker-type
• code-splitting/between-workers
• code-splitting/multi-entry
• code-splitting/dynamic-import
• code-splitting/multi-pages
• code-splitting/shared-references-between-chunks
• hashing/asset-of-asset-cascade/css
• hashing/asset-of-asset-cascade/svg
• non-js-resources/binary/arraybuffer
• non-js-resources/binary/url
• non-js-resources/css/module
• non-js-resources/css/source
• non-js-resources/css/url
• non-js-resources/dependencies/basic
• non-js-resources/dependencies/deduping
• non-js-resources/image/data-url
• non-js-resources/image/url
• non-js-resources/html/inlining-scripts
• non-js-resources/html/loading-scripts
• non-js-resources/html/preload-assets
• non-js-resources/html/preloading-script-deps
• code-splitting/splitting-modules/dynamic-import
• code-splitting/splitting-modules/multi-entry

[jakearchibald]

Suggested change

	esbuild supports tranpiling javascript and typescript code, however, it lacks few transforms when targetting ES5 build target. The output of esbuild can certainly be passed to babel, but esbuild does not provide any mechanism to achieve that.
	esbuild supports transpiling JavaScript and TypeScript code. However, it lacks a few transforms when targeting ES5 build targets. The output of esbuild can be passed to babel, but esbuild does not provide any mechanism to achieve that.

Might need to look a bit more closely to decide if there's a way to make this a pass or not. If not, we should file an issue with esbuild and include it here.

[mischnic]

(evanw/esbuild#297)

[jakearchibald]

From a recent comment on that thread, it looks like https://esbuild.github.io/api/#write could be used here to post-process the output. I'm not 100% sure that makes it a 'pass', but it'd be good to have the example.

This could also be done as a loader plugin. A loader plugin would allow babel to import its polyfills, which could be code-split. The loader route is probably best.

[osdevisnot]

Technically the rules do allow custom plugins regardless of their adoption or popularity, so it would be fair to use a babel plugin, and change the result to 'pass' here.

[jakearchibald]

@osdevisnot looking good so far!

[ryanprior]

Hey folks! As an esbuild user myself who's quite enjoying the tool already, I still would not recommend adding it to this tooling report yet. I say that because it's been changing rapidly and upstream does not recommend it for production use yet.

Hey @evanw what's your feeling, is this is a good time to add esbuild to https://bundlers.tooling.report?

[jakearchibald]

Suggested change

<svg width="164" height="164" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><defs><linearGradient x1="50%" y1="0%" x2="50%" y2="100%" id="a"><stop stop-color="#DEF6FF" offset="0%"/><stop stop-color="#8CD8FF" offset="100%"/></linearGradient><linearGradient x1="50%" y1="0%" x2="50%" y2="100%" id="c"><stop stop-color="#4FB3FF" offset="0%"/><stop stop-color="#2A83F9" offset="100%"/></linearGradient><linearGradient x1="50%" y1="0%" x2="50%" y2="100%" id="d"><stop stop-color="#FFC700" offset="0%"/><stop stop-color="#FF9600" offset="100%"/></linearGradient><path d="M82.5 22.3l50.962 29.422a1 1 0 01.5.867v58.845a1 1 0 01-.5.866L82.5 141.722a1 1 0 01-1 0L30.538 112.3a1 1 0 01-.5-.866V52.589a1 1 0 01.5-.867L81.5 22.3a1 1 0 011 0z" id="b"/></defs><g fill="none" fill-rule="evenodd"><g transform="rotate(150 82 82.011)"><use stroke="#FFF" stroke-width="18" fill="url(#a)" xlink:href="#b"/><use stroke="url(#c)" stroke-width="10" xlink:href="#b"/></g><path d="M91.09 4.19a3.996 3.996 0 015.03 4.242h0L90.508 67.01l31.766.001a2.99 2.99 0 012.122.879 3 3 0 01.482 3.613h0L75.331 157.96a3.987 3.987 0 01-2.423 1.871 3.996 3.996 0 01-5.03-4.242h0l5.61-58.58-31.763.001a2.99 2.99 0 01-2.122-.879 3 3 0 01-.482-3.613h0L88.669 6.063a3.987 3.987 0 012.423-1.872z" stroke="#FFF" stroke-width="4" fill="url(#d)"/><path stroke="#FFF" stroke-width="18" d="M82 82.011l24 41.57-24-41.57H34h48l24-41.57z"/><path stroke="url(#c)" stroke-width="10" transform="rotate(150 82 82.011)" d="M82 82.011l-47.631 27.5L82 82.011v-55 55l47.631 27.5z"/></g></svg>

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 164 164"><defs><linearGradient id="a" x1="50%" x2="50%" y1="0%" y2="100%"><stop offset="0%" stop-color="#DEF6FF"/><stop offset="100%" stop-color="#8CD8FF"/></linearGradient><linearGradient id="c" x1="50%" x2="50%" y1="0%" y2="100%"><stop offset="0%" stop-color="#4FB3FF"/><stop offset="100%" stop-color="#2A83F9"/></linearGradient><linearGradient id="d" x1="50%" x2="50%" y1="0%" y2="100%"><stop offset="0%" stop-color="#FFC700"/><stop offset="100%" stop-color="#FF9600"/></linearGradient><path id="b" d="M82.5 22.3l51 29.4c.3.2.5.5.5.9v58.8c0 .4-.2.7-.5.9l-51 29.4a1 1 0 01-1 0l-51-29.4a1 1 0 01-.5-.9V52.6c0-.4.2-.7.5-.9l51-29.4a1 1 0 011 0z"/></defs><g fill="none" fill-rule="evenodd"><g transform="rotate(150 82 82)"><use fill="url(#a)" stroke="#FFF" stroke-width="18" xlink:href="#b"/><use stroke="url(#c)" stroke-width="10" xlink:href="#b"/></g><path fill="url(#d)" stroke="#FFF" stroke-width="4" d="M91 4.2a4 4 0 015.1 4.2h0L90.5 67h31.8a3 3 0 012.6 4.5h0L75.3 158a4 4 0 01-7-.2 4 4 0 01-.4-2.2h0L73.5 97H41.7a3 3 0 01-2.6-4.5h0L88.7 6.1A4 4 0 0191 4z"/><path stroke="#FFF" stroke-width="18" d="M82 82l24 41.6L82 82H34h48l24-41.6z"/><path stroke="url(#c)" stroke-width="10" d="M82 82l-47.6 27.5L82 82V27v55l47.6 27.5z" transform="rotate(150 82 82)"/></g></svg>

Bit smaller

[jakearchibald]

@ryanprior I agree that reviewing it too early could result in a low score that puts folks off, and that wouldn't be fair if the tool isn't recommended for production. However, if you look at https://esbuild.github.io/, it already compares itself very favourably to the other tools on https://bundlers.tooling.report/ without mentioning any of the pitfalls, so a more thorough feature review might address this.

WDYT @evanw?

[evanw]

Thanks for the ping. It's great that you're interested in adding esbuild to bundlers.tooling.report. I have been watching the download stats on npm and it does indeed look like esbuild has been getting a lot of usage recently.

However, it's still kind of early for this IMO. I'm focusing on giving esbuild a solid core and then slowly expanding the use cases that it can address. Right now esbuild is a great fit for bundling JS-only libraries and has seen a lot of adoption in that space (e.g. used for JS bundling in Snowpack, Hugo, and AWS CDK).

But I'm still busy working on the core of JS support. I'm almost done but code splitting and top-level await, my last big JS feature release, is unfortunately taking a while. I don't think esbuild by itself is a great fit yet for bundling fully-featured web content, and I expect it would score pretty poorly.

Rest assured I absolutely have the web content use case in mind and I plan to address a lot of use cases after solid JS support is in place. But I want to focus on JS tooling first both because I don't want to spread myself too thin and because people are now relying on esbuild's JS capabilities for real work. IMO the right thing to do is to get JS support to a solid place instead of getting distracted by other web content needs right now.

Ideally esbuild's JS support will be complete sometime in Q1, or maybe start of Q2 if it goes long. After that point I plan to focus on CSS and plugins. In that second phase, I will likely have more of the bandwidth and desire to address many of the web-specific use cases in this report.

So if it's all right with you, I'd like to hold back on this for a bit. Let's keep this PR around to track this work and pick it up when esbuild is more ready to address the feedback that putting esbuild on the report is likely to generate.

[jakearchibald]

@evanw That makes sense to me. It'd be nice if some of this was clear from https://esbuild.github.io/, because right now it feels like it sends a pretty strong "we are better than the rest" message. Maybe a little roadmap would be useful, to highlight the progress of the project.

I'm really excited about esbuild, and I'd love to give it a spin when it's nearer ready for web content, which is where I'd personally benefit from a better-performing bundler. At a glance, I'm really happy with the direction and strategy of the plugin API too.

@osdevisnot thank you for your work on this so far, but let's wait until esbuild is more production-ready for web projects.

[evanw]

The roadmap currently is documented here: https://esbuild.github.io/faq/#upcoming-roadmap. Perhaps it should be more prominent. FWIW we're not using esbuild at Figma yet where I work due to lack of more advanced CSS support, so I'm not even using it in production yet.

[jakearchibald]

I'm excited about the CSS stuff. It's something I've really struggled with in Rollup.

[AliMD]

I am impatiently and eagerly awaiting the result of this PR.
And I'm waiting for @evanw signal to migrate to esbuild ;)
with the best wishes. ❤️

[AliMD]

@jakearchibald And eagerly awaiting for your next HTTP 203 about esbuid 😍
(esbuild can really be a game changer in the community and needs supports at the beginning to grow better.)