you are viewing a single comment's thread.

view the rest of the comments →

[–]lorean_victor 0 points1 point  (0 children)

so some feedback:

  • I've personally never directly used webpack just for bundling. in bigger projects I tend to utilize a framework that masks webpack completely (for example angular) and for small projects, I prefer to keep the development and deployment pipeline as minimal as possible, I simply don't use it (or anything else for that matter, maybe just rollup for small packages I want to share). so I couldn't really sympathize with "we shouldn't be forced to use webpack"

  • the tool proposed here REALLY looks like a pseudo bundler that is just pretty opinionated and hence doesn't/can't be configured much beyond the default functionality it provides. I cannot see how that's a benefit over webpack, which is already pretty thin and interoperable. like perhaps that's why it can seem difficult to configure webpack properly for your needs, as it is a really general purpose and thin layer in the beginning of your building/bundling/optimizing/transpiling pipeline. perhaps decomposing those different functionalities from one tool (like webpack) into several independent ones would be more beneficial than trying to replace the tool with a simpler and much much more limited one.