update webpack to 4.2.0

MadeInHaus / react-starter

A client-side SPA starter bundled with React, Redux, CSS Modules, React Router 4, and Webpack 4

MIT License

9 stars 2 forks source link

update webpack to 4.2.0 #32

Closed CaioMatias closed 6 years ago

CaioMatias commented 6 years ago

minor version pump into dependencies
small change in client entry so it can accept other functions later (preloadCSS, initOffline)
config fixes for webpack version pump

rynocouse commented 6 years ago

I think we should move (inline) all build configs that webpack uses into webpack (.babelrc, postcss.conf.js, etc)

Few things I'd like us to consider:

Remove the magical merge.smart (one more set of docs I have to read to understand what's happening w/ the webpack config)
Building a single webpack file and overriding things as needed for dev based on NODE_ENV. (this could be a seperate PR)

chrisjcodes commented 6 years ago

I am actually partial to splitting configs out by what they handle i.e. JS, CSS, Assets, etc and merging them in the configs right before exporting so they are more approachable and its easy to see how a given import type is processed rather than a monolithic config for all import types.

rynocouse commented 6 years ago

I'll take a "monolithic" config over the current magic. Looking at webpack.base there's no way for me to know it's using postcss.conf.js or .babelrc. It's by each individual loaders convention. You have to sift through each loaders documentation to figure out they're loading a arbitrarily named config file in the project root. I'm cool keeping them seperate if we explicitly import them and put them in a folder. Also another issue we need to address is we are defining our browserlist in two places

chrisjcodes commented 6 years ago

100% agree on moving all configs that webpack uses into webpack and doing away with rc files. My approach is a little more similar to the old gulp setup in the you would have separate files for each loader type and that file would have both dev and prod configs being setup and exported and then in an index.js we would merge them into one config for each environment.

I agree right now its hard to follow whats happening because its both a monolith and we merge those monoliths to create environment configs.

For all intents and purposes if this PR works with our code as is, I say we merge once comments have been addressed and take a bigger refactor effort into another branch

rynocouse commented 6 years ago

I agree, If this works let's merge.

stevescavo commented 6 years ago

@rynocouse @unruffledBeaver: we'll need to do some decent amount of testing on this upgrade. If it check out, I'm okay with merging it in as a bump to 4.x is nice. We can riff on our overall webpack config in a separate PR.

stevescavo commented 6 years ago

I unintentionally closed this PR. Reopening.