4 ms·

No, because CRA explicitly encapsulates and hides all that functionality inside the `react-scripts` package. You only add a single dependency to your own app's

No, because CRA explicitly encapsulates and hides all that functionality inside the `react-scripts` package. You only add a single dependency to your own app's `package.json`. All the config files are in `node_modules/react-scripts/config` if you really want to look at them, but otherwise they're effectively hidden. In return, you get: - A Webpack+Babel build config that has excellent default behavior out of the box for browser support and code splitting, and supports working with many common types of assets including images, CSS, and SASS - The Jest unit test runner configured to automatically pick up any test files - A linting ruleset that only warns for potential errors - An error overlay that pops up whenever there's a UI crash, minimizes irrelevant parts of the stack trace, and lets you jump to the relevant lines in your editor - The ability to easily update to improvements in the build system (such as this 3.3.0 release) simply by updating the `react-scripts` dependency. And, CRA has had a _ton_ of work put into it to smooth over various pain points and incompatibilities between browsers, Node, and the various tools that it's built on. While CRA doesn't have a built-in way to override its config files, there are several widely used "CRA override" tools like `craco` [0] that allow you to opt-in to modifying parts of the config to suit your needs. I personally no longer have a need to "eject" a CRA project, as the override tools are more than sufficient to let me make whatever config edits I need (such as [1]). CRA has eliminated the question of "How do I set up a working build setup for a React project?", and made it way easier for folks to write tutorials that focus on the code, not the build setup. [0] https://github.com/gsoft-inc/craco https://github.com/gsoft-inc/craco [1] https://github.com/markerikson/cra-spectacle-mdx-boilerplate/blob/master/config-overrides.js https://github.com/markerikson/cra-spectacle-mdx-boilerplate...

JMTQp8lwXL 7y ago
Correct me if I'm wrong, but if you eject, all of those files and NPM dependencies are just dumped into your main package, even if you didn't need that configuration? E.g., let's say CRA supports SCSS files. You eject and now you have a webpack config that can handle SCSS files, but your project doesn't use them. Now you have white noise. A really small, and potentially trivial example, but that sort of buildup is death by a thousand cuts to a project. "What does this line do?" "Do we need it?" future engineers will ponder. Also, it'd add more substance to the discussion, but I really am curious how many people eject. Is it, the minute it (CRA) can't do what you need, you have to eject? Or it becomes exceptionally difficult to interface with a tool that just abstracts away more tools? It's possible those abstractions might not give you the full level of customization would could potentially need, if project requirements shift. CRACO seems like an admission that CRA, on its own, could be somewhat half baked. The ability to want to override some things without fully ejecting seems like an obviously wanted feature of a toolkit.
- acemarke 7y ago
  Yes, that's what happens if you eject. But the point is that ejecting is an absolute last-ditch option that almost no one should have to resort to. Most folks won't need to customize the standard CRA behavior. If you do, there's the community override tools. As a specific example, two years ago I wrote a tutorial on how to use the Cesium 3D globe library with Webpack [0]. Loading Cesium at the time required changing two Webpack config options, so my tutorial started with "create a CRA app, then eject". I recently set up a brand new CRA project that also uses Cesium. I could have used `craco` or a similar override tool to apply those Webpack config tweaks myself, but there's actually a `craco-cesium` plugin [1] that applies those edits and handles copying Cesium's assets to the CRA build output folder. This new project didn't have to eject at all. As another example, that same project also needed to do more customization to the dev server proxying setup than CRA normally allows. CRA lets you define a simple `"proxy"` option in `package.json`, or a `setupProxy.js` file that gets a reference to the Express app to add middleware. I actually needed to apply a proxy middleware at the _end_ of the chain. `craco` let me access the actual Webpack config setup to do that [2]. The other nice thing about these override tools is that your modifications are isolated in one place, so you know exactly what changes are being made. If I were to eject and get all those config files in my project, yeah, I wouldn't know what had been edited from the originals without digging into the Git history. This way, it's one `configOverrides.js` file at most, and I get all the benefits of the rest of CRA's config which has had thousands of man-hours put into it. [0] https://blog.isquaredsoftware.com/2017/03/declarative-earth-part-1-cesium-webpack/ https://blog.isquaredsoftware.com/2017/03/declarative-earth-... [1] https://github.com/darwin-education/craco-cesium https://github.com/darwin-education/craco-cesium [2] https://twitter.com/acemarke/status/1152371310682607618 https://twitter.com/acemarke/status/1152371310682607618
- korla 7y ago
  Don’t eject. The point of CRA is to abstarct away the current way to set up the build system. Instead let the guys behind CRA tune it, handle upgrades, etc. in complex projects the time spent configuring webpack and keeping versions in sync is quite severe. CRA lets you sidestep this. Somewhat.
  - 7y ago

JMTQp8lwXL 7y ago

Correct me if I'm wrong, but if you eject, all of those files and NPM dependencies are just dumped into your main package, even if you didn't need that configuration? E.g., let's say CRA supports SCSS files. You eject and now you have a webpack config that can handle SCSS files, but your project doesn't use them. Now you have white noise. A really small, and potentially trivial example, but that sort of buildup is death by a thousand cuts to a project. "What does this line do?" "Do we need it?" future engineers will ponder. Also, it'd add more substance to the discussion, but I really am curious how many people eject. Is it, the minute it (CRA) can't do what you need, you have to eject? Or it becomes exceptionally difficult to interface with a tool that just abstracts away more tools? It's possible those abstractions might not give you the full level of customization would could potentially need, if project requirements shift. CRACO seems like an admission that CRA, on its own, could be somewhat half baked. The ability to want to override some things without fully ejecting seems like an obviously wanted feature of a toolkit.

acemarke 7y ago
Yes, that's what happens if you eject. But the point is that ejecting is an absolute last-ditch option that almost no one should have to resort to. Most folks won't need to customize the standard CRA behavior. If you do, there's the community override tools. As a specific example, two years ago I wrote a tutorial on how to use the Cesium 3D globe library with Webpack [0]. Loading Cesium at the time required changing two Webpack config options, so my tutorial started with "create a CRA app, then eject". I recently set up a brand new CRA project that also uses Cesium. I could have used `craco` or a similar override tool to apply those Webpack config tweaks myself, but there's actually a `craco-cesium` plugin [1] that applies those edits and handles copying Cesium's assets to the CRA build output folder. This new project didn't have to eject at all. As another example, that same project also needed to do more customization to the dev server proxying setup than CRA normally allows. CRA lets you define a simple `"proxy"` option in `package.json`, or a `setupProxy.js` file that gets a reference to the Express app to add middleware. I actually needed to apply a proxy middleware at the _end_ of the chain. `craco` let me access the actual Webpack config setup to do that [2]. The other nice thing about these override tools is that your modifications are isolated in one place, so you know exactly what changes are being made. If I were to eject and get all those config files in my project, yeah, I wouldn't know what had been edited from the originals without digging into the Git history. This way, it's one `configOverrides.js` file at most, and I get all the benefits of the rest of CRA's config which has had thousands of man-hours put into it. [0] https://blog.isquaredsoftware.com/2017/03/declarative-earth-part-1-cesium-webpack/ https://blog.isquaredsoftware.com/2017/03/declarative-earth-... [1] https://github.com/darwin-education/craco-cesium https://github.com/darwin-education/craco-cesium [2] https://twitter.com/acemarke/status/1152371310682607618 https://twitter.com/acemarke/status/1152371310682607618
korla 7y ago
Don’t eject. The point of CRA is to abstarct away the current way to set up the build system. Instead let the guys behind CRA tune it, handle upgrades, etc. in complex projects the time spent configuring webpack and keeping versions in sync is quite severe. CRA lets you sidestep this. Somewhat.
- 7y ago