[Feature Request]: Let's rework some of the main scaffolding layout

[TheLarkInn]

Describe the solution you'd like
Let's rework how development and production configs are laid out.

• Always no matter what, config is generated in root of project
• Config is generated IF defaults are not used
• Config is always named webpack.config.js
• Development and Production configs are composed or combined using webpack-merge not Object.assign
• Development and Production configs use names webpack.development.js and webpack.production.js (even if shorter is more convenient it matches with mode names).
• Scripts generated should use --env.mode development --env.mode production to determine whether or not production or development modes are used.
• any config used is a function that returns a config.
• any config that is needed for both production and development goes into the webpack.config.js file, or the common config.
• For multipage application we do not use webpack-dev-server in dev, and instead use --watch in scripts.
• For SPA (or single entry) we consider using webpack-dev-server as default instead of --watch
• Dev script is called dev and production script is called prod.
• A script called webpack is generated so users can run npm run webpack. This will be used inside of dev and prod scripts for composition sakes.

Hopefully all of this is clear and I added them in checkbox format. These ideas I've created based on positive feedback I've received from my workshops and talks.

Since all this code is JavaScript i would understand that there are many opinions on how configs are formatted but I would like to go this direction because I believe it is just easier to maintain this way.

If you look at my repo: https://github.com/TheLarkInn/webpack-workshop-2018/tree/feature/19-sm-css-code-split

This shows you a fully fleshed out example with many features, integrations, etc and hopefully we can follow this style (even presets which I can document in a separate issue).

[EvsChen]

Are we going to track these feats in this issue? I would like to handle some of them.

[evenstensberg]

Probably. If there's no PR's open, take one down @EvsChen , thanks!

[EvsChen]

I guess I'll handle the config naming first.

[evenstensberg]

I've already submitted a PR for that. Other than that, up for grabs

[anshumanv]

Working on 1 - Generate webpack config in the root of the project. 😄

[anshumanv]

I have a question, what's the workflow when defaults are used? (Point 2)
@evenstensberg @dhruvdutt

[evenstensberg]

Then we run the init generator

[anshumanv]

Cool!

Working on point 2 - Run init generator when defaults are used, thanks @evenstensberg! 😄

[anshumanv]

A script called webpack is generated so users can run npm run webpack. This will be used inside of dev and prod scripts for composition sakes.

I think I have an approach in mind, will be sending a WIP soon. 👍

[webpack-bot]

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[webpack-bot]

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.