I know. I know. Blasphame, but I really hate [Webpack](https://webpack.js.org/), not the idea of it but what it turned web development into - a bloated tangled mess of **headaches you don't need**.
[Webpack](https://webpack.js.org/) became the defacto go-to solution to get the latest [es6](http://es6-features.org) javascript language functionality into a developers pipeline via transpilers like [Babeljs](https://babeljs.io/) and support the overly bloated non-standard web component soultion as the [ReactJS](https://reactjs.org/) framework (batteries NOT included). Sure [Webpack](https://webpack.js.org/) does more or can do more, but in the end developers just want to develop with [es6](http://es6-features.org) features, **however** this was only supose to be a temporay *polyfill*, until browsers started supporting the next version of Javascript -- ES6.
Dont know about you, but tinkering around with configurations all day, and watching build processes move ever **S L O W E R** is not what I signed up for.
Stop getting distracted by the *shiny* future that *may* never come, and focus on the here and now. **Here** and **now** is pretty awesome. We have native ES6 language support in all evergreen browsers.
But I hear you screaming at the screen, **what about minification**, and ES5 support, and...
I know [WebPack]() has its uses, or rather a build process has its uses, but a lot of that can be done much simpler...simpler for any developer to understand -- like [Gulp](). A few *gulp* scripts could solve your problem, and you can break-up to operations, combine and mix and match as is important to each developer.
My biggest advocate for having a build process is for the final build, aka **PRODUCTION**, but code-by-the-hour should just work -- everywhere, as the web was designed.