Hacker News Reader

Comment by no_wizard | Hacker News Reader

Something webpack doesn't get right to this day: building consumable libraries.

It has all the bones, and it would be great if it did, as its extremely powerful at manipulating the AST as part of the process etc so you could do some neat optimizations, but it won't output to a standard format, even with experimental ESM output feature enabled, that makes the library reasonably consumable.

Rollup / Vite really excel here but I love competition pushing things forward, meaning webpack having a better library building experience would be a good thing.

View on HN

I was actually looking into building a library today with Webpack and ran into similar problems. But could you help me understand what you meant here?

> but it won't output to a standard format, even with experimental ESM output feature enabled,

Are you saying ESM is not a standard format? Or that the ESM output doesn't actually follow standard ESM? Or maybe you meant something else entirely?

Trying to make ESM actually work in the JS ecosystem is still wildly experimental and incredibly painful. https://blog.isquaredsoftware.com/2023/08/esm-modernization-...

It's bad for them because their support matrix still includes versions of Node and webpack that haven't been in even LTS support for years at this point.

It's great that they want to support such a long tail. I know that makes a lot of developers very happy that they can rely on that.

In my experience ESM is not painful at all if you can rip the bandaid off and drop Webpack 4 (and below) and any version of Node less recent than current LTS. That's a lot easier done in greenfield projects than those that have long tail support matrices to contend. Brownfield projects should get better as more and more of that tail dies off.

opposite issue, webpack doesn't output plain ESM code for libraries (IE, no __webpack__require__ etc.). Its both experimental and sometimes completely incorrectly generated, while still generating library code with webpack specific references.

esbuild any day. JS tooling doesn't need to be written in JS, and when it's not, it's properly blazing fast.

Vite uses esbuild under the hood. Providing much nicer DX

Depends on what you need, tbh. I looked into Vite briefly but esbuild seemed more obvious/ direct for hooking into the build system.

At this point in my life I think "DX" - if you mean things like performance, reliability, simplicity and maintainability - is inversely proportional to the amount of (transitive) dependencies, layers of abstraction and (only half jokingly) also the percentage of JS that something includes.

I've encountered a pretty back breaking memory leak in vite that has been unresolved for about 2y now. The project I work on that uses vite doesn't need the flexibility, feature set and plugin system that vite offers. It just needs a fast bundler.

esbuild has a decent DX and for some projects (especially libraries) the extra bells and whistles of Vite can be YAGNI.

My complaint with esbuild is it doesn't use `tslib` nor does it have its own sharable helpers like it that can be shared across builds, so you have all this repeated code that doesn't treeshake away.

If it did, I'd use esbuild in a heartbeat for libraries.

It also uses generic polling for watchmode, I'd like to see something more robust

Can't say I've every used esbuild for watching, mostly because if I'm running in dev mode, I'm going to load "my files", not a bundle. The bundle is only for final delivery, so it needs to pass tests, but that's a precommit step, not a continuous development process.

monorepo setups is where you will likely find this to be more of an issue, especially if you spin up watch mode on several libraries that may be undergoing changes

Reply on news.ycombinator.com