Why I built CRACO
I’ve been asked a few times why I built CRACO. This is a good question and I thought it was worth writing a post about it.
What is CRACO?
CRACO stands for Create React App Configuration Overide.
Short and sweet, it’s an hacky layer on top of Create React App (CRA) to customize it’s configuration.
This is achieved by overriding the cache of the require calls made by CRA to replace the exported content with our customized configuration.
Cool, but why?
Webpack is hard, REALLY hard. The documentation is heavy, the possibilities are endless and you have to deal with a ton of community packages to end up with the optimal configuration for your project.
Add React to the mix and the complexity increases tenfold.
Initially, when you’re building the configuration for your new and shiny project you will get use to Webpack. You might end up thinking that after all it’s not so bad. Future changes should be easy to do.
It’s a lie!
When you will be required to update your Webpack configuration 2, 3 maybe 4 months later you will have to start over and read all the documentation again.
You will probably end up asking yourself the same questions you answered a few months before. There’s even a possibility that a new major version of Webpack had been released during those months.
All this happened to me a few times.
What’s the solution?
You can use CRA to abstract all this complexity for you. In a few minutes you will have a working, almost blank, React project with development, production and test scripts.
The maintainers of the project have great knowledge of Webpack and React and you can leverage it for free. Even the great Dan Abramov contributes to the project.
But there’s a catch…
They enforce a zero customization policy. To only name a few, here’s a list of major pieces that you can’t customize:
- Babel
- Webpack aliases and plugins
- Webpack dev server
- PostCSS
- ESLint
This is not acceptable for a commercial project with a large team. How can I tell my Senior Web Integrator that he cannot use a well adopted PostCSS feature like nesting-rules because I made the decision to use CRA and they enforce a zero configuration policy?
You can always eject, but the generated code requires a lot of knowledge. You end up with something that is harder to maintain than the original Webpack configuration you would have written. Furthermore, you will not benefit from future CRA updates.
I was in the process of giving up on CRA when I discovered react-app-rewired. It saved the day by giving us the ability to customize CRA configuration at build time. It worked well for a while.
Then a new major version of CRA was announced and the react-app-rewired author made it clear that he wouldn’t update the package to make it compatible since he didn’t use it anymore.
That’s how CRACO was born!
