Most people don't remotely know how Webpack works. And they shouldn't have to! Same for most other developer tools. You need a few people who can dig out issues if they arise, but most of your people will be concerned with actually building things on top of those tools.
When every team starts a new project from every few months to every few years, having a boilerplate setup quickly becomes very valuable. The added benefit that third-party boilerplate has is that you don't have to maintain the whole lot yourself.
Needless to say these upsides don't come without issues, security and accountability being the big elephants in the room, but popularity helps here, too. The boilerplate is used by a lot of people, in organizations both big and small. If an issue arises, you can usually collectively work out the problem very quickly. It doesn't make the issues go away, but it gives you a good balancing point.
As a tradeoff versus either setting up every project manually or maintaining your own boilerplate project, it's definitely worth consideration — it might not match your needs, but it's a strong option.
I think maybe I just struggle with the concept of being that hands-off with the tooling. I don't think I could cede control to some one-size-fits-all solution. For example, what happens when you run into some important library that doesn't tree shake or minify properly? What do people do? Do they just pick different libraries for the wrong reason? Do they just deploy an un-optimized application?
Not knowing how the stuff you depend on works feels really scary to me. Reminds me of the Star Trek TNG episode about "The Custodian" where the colony came to depend on a tool that nobody knew how to fix, so their lives were shaped by the tool's abilities, not the people's desires.
And on top of that, it's all different now. I'm not as interested in trying to maintain all of that, on top of maintaining my app. CRA is a fantastic tool for this.
Until it breaks down leaving the project in an unmaintainable state, you're right. Then it's a scramble to understand and update that in my experience usually results in locking that dependency down to a strict version number and hoping that won't break anything else. It's great for security as pointed out in this thread /s. Not the optimal solution, but then again, they don't pay me enough/have enough staff for the optimal solution. And this is code that isn't even part of the app! Just shitty tools preventing me from even building the app. I can relate to the people complaining on here. This is with one or two dependencies too. Try solving those issues a few thousand times. You'll wish this horrific trend of front end code compilation would just stop. The problems truly never end as soon as one has to deal with npm and js dependencies. Which is not to say other languages don't have the same problems. They do, just not on this epic scale of shit.
mkdir parceldemo
cd parceldemo
yarn init
vi index.html
vi index.tsx
npx parcel index.html
...and I have a working React app, with hot module reloading and TypeScript. Parcel installs TypeScript as a devdependency and react and react-dom as dependencies, and starts the HMR server. It took less than one minute.
Its the opposite. You create a new app so infrequently that its not worth learning how to do it yourself. Just run the tool once and its all set up and you can forget about it.
I used the vuejs equivalent and it set up everything in a usable way and I have been happily developing without having to change any of those configs set up for me.
First, it allows React learners to set up an environment without having to learn Webpack and Babel first. Prior to that, most tutorials would waste multiple pages on "Before you can do anything else, here's how to set up a Webpack+Babel config..."
Second, it allows experienced React devs to spin up a project without having to do all the configuration work (or copy and paste it from somewhere). It also provides good defaults for build output, lints for common mistakes, and makes it really easy to get future build improvements just by updating a single `react-scripts` dependency.
Third, it also acts as a common starting point for instructions and tutorials. For example, I wrote a blog post a while back on using the Cesium.js 3D globe library with Webpack and React ( http://blog.isquaredsoftware.com/2017/03/declarative-earth-p... ), and I was able to start by just saying "Create a CRA project, eject, and modify these two config values".
When I used CRA for a project about a year ago, it spit out a gigantic README with everything anyone ever might want to know about JS development, it had a long webpack configuration that hot-loaded CSS and auto-reloaded the page on JS edits, it set up the app to use a service worker, and it used a ton of other technologies and libraries and tools that I didn't know existed. They've scaled it back quite a bit since then, but I think getting a feel for what's out there is really valuable, and even though it has way more than you need, it's nice to be able to easily try those things to learn what they are and confirm that you don't need them. Otherwise, you might end up with a community of people who don't know about ESLint because none of the tutorials thought it was critical to set up before getting started.
One mindset (not necessarily for beginners) is that when working on a serious project that will need non-trivial config, it's best to run create-react-app, eject, carve away all of the unnecessary stuff that you don't want, then take ownership over every aspect of the build system and tooling. That leaves you with a much more solid starting point than if you start totally from scratch and only add things as you need them.
Even if you do stuff by hand you can run CRA and see how the experts do it.
The unfortunate thing about CRA is that it's another tool on top of a tool to learn. It's not just instant and obvious, it has its own layer of configuration and understanding of how not to break it, how to upgrade it, etc. So people spend time learning the tool's tool instead of the tool.
I'm also not convinced this is "how the experts do it."
Create React App is by default zero configuration and we do our best not to make it possible to break it. For example you cannot access the configurations of Webpack for this reason. We do allow some configuration through environment variables[0] but try to minimize amount of those too (and some of them will probably get removed in future version too). The public API is around 4 commands (start, build, test, eject).
This makes it possible to make big changes underneath the package in even minor versions (eg. updating major version of Webpack) without breaking existing CRA-powered apps. You can see migration guides for every single version in the Changelog, usually consisting running a single command[1]. This was also true for the major update from 1.x to 2.x [2]
[0](https://facebook.github.io/create-react-app/docs/advanced-co...)
[1](https://github.com/facebook/create-react-app/blob/master/CHA...)
[2](https://github.com/facebook/create-react-app/blob/master/CHA...)
That said, it does take some effort to understand the benefits and limitations of CRA. How could we improve on that one?
Disclosure: Doing maintenance work on CRA
I tried it and in order to satisfy everyone's needs it seems like overkill tooling for most needs.