Distributing the Transform API as a standalone package

[privatenumber]

I'd like to suggest separating the Transform API into its own npm package.

esbuild's distribution size is around 10MB, which may be due to features like the CLI, bundler, builder, watcher, and server. The Transform API alone might have a significantly smaller footprint.

Many tools rely on esbuild solely for transformations without requiring other esbuild functionality. Separating this API could reduce disk usage and install time across npm installations, benefiting the ecosystem and users who only need transformations.

I understand this may introduce a maintenance burden and may not align with esbuild's compiled Go-based architecture. Still, I'd appreciate any insights on whether such a separation might be feasible and beneficial.

Thank you!

[evanw]

I sympathize with the size problem, but unfortunately esbuild was never designed for this use case. If I did design esbuild for this use case, then I wouldn't have used Go at all. AFAIK Go is unsuited for this as it's doesn't optimize for small binary size. There's lots of GC metadata and the standard library and runtime is included in the binary (and is not small). I believe the thinking is that Go is designed for servers and server disk space is considered to be cheap.

That said, one of the bigger size reductions could come from removing the system network library. Adding the development server was one of the few times when esbuild's binary size increased the most dramatically. This brings the binary size from 9.3mb to 6mb. Not the biggest win, but something that's easily doable. But it's not going to be able to compete with a purpose-built library that optimizes for this, which I'd expect to be at least an order of magnitude smaller.