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
• [x] transformations/dead-code
• [x] transformations/dead-code-dynamic
• [x] transformations/flags
• [x] transformations/minify-js
• [x] 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]

@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]

@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.)