Eject webpack config
egoist opened this issue · 7 comments
I haven't really tried to implement this, but should not be hard!
I'd love this
@ZakTax currently it won't be possible unless neutrinojs/webpack-chain#25
@ZakTax Why would you ever want to do that?
If I may, I think that would be a terrible idea. If someone wants to go all-webpack they easily can do that. Just don't go with POI and you're all set.
Poi, just like a boilerplate is a starter kit of a working practice (didn’t want to say best) that allows you to start working right away. As your app or environment changes your Webpack needs may too. To give just one example, multiple Webpack entries.
I would much rather start from what I know works (poi’s Webpack config) than build a setup from scratch. Till you graduate from Poi you may not know what goes on under the hood. For some it may be your first meeting with Webpack 🤢
Point being in case you missed it. Eject config may not be such a bad idea.
@mblarsen Well, I hate to say it but I was almost sure someone will say that. In my opinion Webpack as such has become so obscure and so fragile there is a need for a tool that will make it approachable for the rest of us. From what I have been able to see so far POI uses Webpack very much programatically therefore if ever such a process of ejecting configuration would be possible it would need to create whole separate configs for tests, dev and production builds. Despite that I think that the most valid point about using POI is to be able to have upgradable, semi-rigid build configurations. A good example is Maven and Gradle in the Java world: they do propose a directory structure and a build flow but at the same time they allow for extensibility. That extensibility is more packaged than the one currently in use in Webpack but that is OK - somewhere down the line it's best to have an assembler (in both broad and strict meaning of the word) that does the job. However I think everyone will agree that using an assembler these days is not the most common thing. And such is the case with Webpack and POI. I view POI not as "the first step" but the finally captured flow that makes sense and is feature-extensible. From the get go POI defines 3 build types (dev, test, production), does all the things 80% of the projects would do anyways and allows for adding more tooling via preconfigured packages of functionality. Sure those packages would have their own bits and pieces for customization but in my opinion the operative word here is "customization" and not "configuration".
The bottom line that I'd like to get across is not to think about POI as the a bit more advanced starter pack that eventually gets dismissed. That we already have, it's called XXX-cli (or create-react-app) and does exactly what is expected from a project that needs assembler-level manipulation because it is so incredibly specific.
By the way - the more standard layout for a project (but not to restrictive) the easier it is for people to jump from one project to another. It's enough to see that even Gradle picked up the same (or at least very similar) folder structure and build flow as Maven does just to make users comfortable. I think what has been for years now proposed as a structure for frontend projects (src, test/unit, test/e2e) serves at least 80% of the cases. And for those that need that special level of control (good luck upgrading that configuration in 2 years time!) there should be another tool and vue-cli (and other counterparts) do it very well.
Closing since it's impossible (or too complex) with webpack-chain.