4 ms·

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 configur

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.
- Stevvo 7y ago
  Thankfully CRA has improved to the point where ejecting is usually no longer necessary. A few years ago, there came point on almost every serious project where requirement x, y or z forced you to eject.
madeofpalk 7y ago
> Is it, the minute it (CRA) can't do what you need, you have to eject? I don't think there's that many uses cases that can't be done within CRA. I think there's very limited reasons to eject.
the_other 7y ago
I ejected my app, and I regret it. Re-loading ny app i to a new CRA harness seems possible but fiddly. The last time I tried I got bogged down in dependency hell because so much had changed (unusual things like my auth library failing when backed by a more modern React). It all remains on the long-term aims list.

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.

Stevvo 7y ago
Thankfully CRA has improved to the point where ejecting is usually no longer necessary. A few years ago, there came point on almost every serious project where requirement x, y or z forced you to eject.

madeofpalk 7y ago

> Is it, the minute it (CRA) can't do what you need, you have to eject? I don't think there's that many uses cases that can't be done within CRA. I think there's very limited reasons to eject.

the_other 7y ago

I ejected my app, and I regret it. Re-loading ny app i to a new CRA harness seems possible but fiddly. The last time I tried I got bogged down in dependency hell because so much had changed (unusual things like my auth library failing when backed by a more modern React). It all remains on the long-term aims list.