This is a great reason to eject. It’s the reason most people do so. However, before you eject, take the time to ensure you aren’t making extra work for yourself or repeating the work someone else has done previously.
There are thousands of issues filed in the Create-React-App repo, and chances are someone has already addressed your concern. Explore the existing discussions around the topic; you might find a solution or alternative already exists. If it hasn’t been discussed yet, consider filing an issue or making a PR. Thoughtful input is always appreciated.
A nice feature of the CRA sub-package react-scripts is that it can easily be forked and modified. The resulting forked configuration can then be used by your project. Try exploring some existing forks of react-scripts to see if they include the features you want, but without having the maintenance burden of managing your own configuration files. React-super-scripts is an example of one alternative that includes decorators, babel stage-0 features, CSS, SASS, and LESS modules:
Before you dive into editing configuration files, you should ask yourself two important questions:
- How much value will be added by making this change?
- Does the value outweigh the introduced cognitive burden of managing the build process?
You’ll be adding thousands of lines of complex code for building and testing, which you will then need to learn in order to properly update, test, and debug your build. By ejecting, you’re taking on the responsibility of updating code that you might not fully understand. If your build breaks, the CRA team will be unable to support your custom configuration. If you have a development team, do you trust they will also adequately understand the changes they’re making to the build process to ensure its stability?
If you or your team do not have a strong understanding of the existing build tools already, “just adding one feature” is likely more difficult than it sounds.
There are a couple of ways to edit your configuration without ejecting. Unlike ejecting, these options are easy to back out of if necessary. React-app-rewired is one of the most popular approaches. Additionally, customize-cra is a package built on top of react-app-rewired with support for version 2 of CRA.
Version 2 of CRA introduced babel-macros, which are an advanced feature that allows for the inclusion of simple code transformations that run during the build process. It makes configuration files unnecessary, just import your macro into the file you want to transform. Babel-macros have a steeper learning curve than the above tools but are a handy escape-hatch from managing the entire build process yourself.
Okay, I get it, your workflow is a special case and needs specific tooling to reflect it. But before you eject, consider that your use case might be more reusable than you think. Rather than ejecting and maintaining the build process yourself, forking react-scripts allows you to make changes while also reusing it on other similar projects.
Allowing others to use and contribute to your build process is good for your code’s stability and maturity. Forking is encouraged by the CRA team, and easy to set up. Auth0 wrote a great instruction guide for how to fork react-scripts.