esbuild VS import-maps

I will use TypeScript with esbuild bundler, which is a fast and highly efficient builder for JavaScript and TypeScript.

Bundling extensions — in general, custom extension formats require custom bundling tools. Currently, as it’s still early, I put everything into a single JSON file with Node.js and esbuild bundler, but I’m exploring how to develop a custom Vite plugin for this purpose;

Chris favours using the ESBuild bundler to work out the shortcomings. ESBuild can bundle CSS files into a single CSS file. ESBuild can transform your natively nested CSS to "flat" CSS -- this is important since nesting is not in Firefox currently. Therefore, with the aid of ESBuild, Chris has feature parity for his usage of Sass. The other Sass features like mixins and inheritance do not appeal to Chris.

Rollup is highly configurable via plugins. It also supports a wide range of transpilation targets. However, it's written in JavaScript (well, TypeScript) so there's a ceiling on how fast it can go. esbuild and swc are orders-of-magnitude faster than Rollup.

Note that `deno bundle` is deprecated. You can almost replace it with esbuild but it currently lacks builtin support for import maps:

    deno run --allow-all https://deno.land/x/[email protected]/mod.js --bundle app.js --outfile=bundle.js. # errors, see: https://github.com/evanw/esbuild/issues/2230

Want to import a package / file conveniently from esm.sh or unpkg or directly from a GitHub repo for a one-off script (for example). To do this I created a custom ESBuild plugin to handle HTTP imports - that worked for ,js files. To support running both ESM and CJS, I use tsx.

esbuild – is an easy-to-configure bundler,

As we iterate on the definition, we are going to want a better developer experience for rebuilding the package on changes. Typically, for a “library” or “utility” style package, I’d reach for either unbuild’s stub concept or use esbuild/tsup/rollup to implement a more traditional watch/rebuild, but in this case, I’m watching a proto file that lives outsides of the source, which breaks assumptions of those tools.

I use ESBuild (https://esbuild.github.io/) as a library for my almost pure Go toolchain, and it covers my requirements for almost 2 years now. ESBuild is the Go tool used in Vite, an incredible tool that I stopped using when I discovered that ESBuild covered all my needs.

As we can see, we have two external dependencies and one internal tool. In the modern way of packaging our application, we would be of course required to package this project using some bundler like ESBuild or Rollup. But with import maps, we can instead utilize CDN's to deliver our packages and completely eliminate the bundling step.

https://github.com/WICG/import-maps/issues/2

Bare specifiers has been the tragedy of ESM. Nice module syntax... that is utterly u deoyable & which has had to have awful de-modularizing specifiers hard-coded into each file to make it work. Abominable sin to introduce "modules" to JS/es2015 then spend a decade dragging everyone along with no story for how to have modular modules.

Import-maps are like "here" to fix this on the web... finally... except they only are shipping to the happiest sunniest easiest case, with Web Workers being totally shit out of luck in spite of some very simple straightforward suggested paths forward. https://github.com/WICG/import-maps/issues/2

I think Deno is making pretty good tradeoffs along the way here. This looks like package.json at surface level, but there is a nightmare of complexity under the surface. Typescript, ESM, cjs all have various pressures they create & in Node it's just incredibly tight & tense dealing with packaging, where-as Deno's happy path of Typescript first does not slowly tatters one over time. It really has been super pleasant being free of the previous world, and having something much more web-platform centric, more intented, with less assembly & less building, and more doing the actual coding.

I really hope import-maps eventually get broader support. Maybe this long-dwelling webworker issue should be brought up with WinterCG.

Import maps proposal

The concept of Import Maps was born in 2018 and made its long way until it was declared a new web standard implemented by Chrome in 2021 and some other browsers.

Huh. I was about to complain that this breaks with web standards, but apparently it's being proposed as a standard feature: https://github.com/WICG/import-maps

Interesting!

Since developers were already familiar with this way of importing packages from npm, a build step was needed to ensure that code written in this manner could run in a browser. This problem was solved by import maps. Essentially, it allows the mapping of import specifiers to a relative or absolute URL, which helps to control the resolution of the module without the application of a build step.

Gladly, no! Because we could write an import-map!

Indeed, import maps seems to be the way to go.