5 ms·

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 powerfu

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.

TheRealPomax 3y ago
esbuild any day. JS tooling doesn't need to be written in JS, and when it's not, it's properly blazing fast.
- thangngoc89 3y ago
  Vite uses esbuild under the hood. Providing much nicer DX
  - IggleSniggle 3y ago
    Depends on what you need, tbh. I looked into Vite briefly but esbuild seemed more obvious/ direct for hooking into the build system.
  - dgb23 3y ago
    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.
  - WorldMaker 3y ago
    esbuild has a decent DX and for some projects (especially libraries) the extra bells and whistles of Vite can be YAGNI.
- no_wizard 3y ago
  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
  - TheRealPomax 3y ago
    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.
    - no_wizard 3y ago
      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
c_s_guy 3y ago
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?
- crooked-v 3y ago
  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-lessons/ https://blog.isquaredsoftware.com/2023/08/esm-modernization-...
  - WorldMaker 3y ago
    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.
- no_wizard 3y ago
  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.

TheRealPomax 3y ago

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

thangngoc89 3y ago
Vite uses esbuild under the hood. Providing much nicer DX
- IggleSniggle 3y ago
  Depends on what you need, tbh. I looked into Vite briefly but esbuild seemed more obvious/ direct for hooking into the build system.
- dgb23 3y ago
  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.
- WorldMaker 3y ago
  esbuild has a decent DX and for some projects (especially libraries) the extra bells and whistles of Vite can be YAGNI.
no_wizard 3y ago
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
- TheRealPomax 3y ago
  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.
  - no_wizard 3y ago
    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

c_s_guy 3y ago

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?

crooked-v 3y ago
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-lessons/ https://blog.isquaredsoftware.com/2023/08/esm-modernization-...
- WorldMaker 3y ago
  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.
no_wizard 3y ago
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.