I really dislike the huge, multi-faceted build systems calling themselves bundlers. An ideal bundler would take a fully working unbundled project, which is eas

I really dislike the huge, multi-faceted build systems calling themselves bundlers. An ideal bundler would take a fully working unbundled project, which is easily writable with JS modules now, and just optimize it for production delivery. The unbundled working app will be easier to develop and debug. Having a working project as input, and working project as output means that you can switch bundlers and aren't tightly coupled to it's transforms. But most bundlers don't work this way (Rollup is the closest, and that's why I use it). Bundlers are typically entire build systems with compilers, CSS transforms, image optimization, etc... and they happen to bundle somewhere in the build pipeline. In the worst cases it's not possible to run the build but _not_ bundle, if you wanted to run some of the transforms. This is all kinds of bad for the JS ecosystem. You can't really tell how a module will behave because the bundler is transforming everything. Imports aren't really imports, CSS is concatenated and magically added to the main document. Sometimes libraries publish code to npm that _only_ works with certain bundlers. Web Bundles[1] is the way out of this. It's a standard bundle format that'll be natively understood by browsers, is unpacked before the network cache, and _only_ a bundling format. If you just want to bundle a working project, any Web Bundle tool will work. [1]: https://web.dev/web-bundles/ https://web.dev/web-bundles/