Great ideas. It seems like this sort of 'sane defaults' functionality could easily be added to future versions of webpack, and that might really help with adoption... rather than this community endlessly switching tool chains.
The main issue is generally that there isn't much of a consensus on toolchain. Are you using vanilla ES6 or TypeScript? If the former, are you sticking to the standard or using class properties and object spread? Are you also adding non-stage3 crap like bind operator and decorators?
For CSS, are you using styled components or Sass? Maybe you're using PostCSS? If so, with which plugins?
Are you doing codesplitting? If so, how? Are you using a DLL plugin for your vendor stuff? Oh, and how would you like to handle far future caching?
For a trivial app there probably can be a default, but unlike something like ESLint, any app that plans on living more than a little bit needs to answer all these questions and the answer is not obvious.
Generally you could stick with some defaults that represent a majority opinion, but right now its so close to 50/50, it's hard. Still could be done though.
https://github.com/ericclemmons/terse-webpack
It seems to have presets for sane defaults on the roadmap.
For an eslint-style plugin system I'd recommend webpack-blocks.
I am myself refusing learning new tools in javascript. I think I have spent enough time learning enough of them. I have a selected set of them, and I turn down projects which fall out of that set. Less money, but better mental health.
and once a group of pack starts going off in one direction, its just a matter of time before everyone is on it. for better or worse, it seems hard to stop this type of movement.
im not sure why this is tbh, because mastering your tools is a big part of becoming a 10x developer, where you are actually productively creating and not just looking up docs half the time.
perhaps this type of fad may be mainly driven by beginning or jr devs who are still undecided on what they want to learn and just go with what seems to be the next cool thing to learn.
but then again without this type of change, we might as well all be still coding in perl. it really sucks to throw away what you invested in for a year or more but its just something you have to accept as a dev and move on these days as a javascript developer.
So that was a period of transition where finally all of the stuff the rest of world had was within our reach. But since we were starting (almost) from scratch, we had a chance to make it better. However, to do that, we had to experiment (and fail a lot).
Thats where you saw all these tools as people iterated on it. It slowed down a lot now, and a lot of concepts bubbled up on top and we're down to only a couple of mainstream options (there's a lot of more obscure ones, but that's true in JVM/backend land too, and that's been around for a while).