If you’re working with React, you’re probably familiar with the create-react-app tool by now. If you’re not: it’s an official command line interface for building React applications with no build configuration.
With no build configuration.
With no build configuration…
With no build configuration!? But we need that! Kind of …
Now wait! Don’t jump on me with the “but it’s just supposed to be a simple tool, it doesn’t need any additional configuration!” argument!
👆 I posted a sneak peek of create-react-app + decorators on Twitter, and it looks like people are interested in it. But “decorators” is only one of the additional features we might need so we can switch to create-react-app for generating and building apps.
Many developers (including me) want to use create-react-app as their main dev setup for React apps but they can’t because they’re missing one or two features.
- Someone needs just SASS.
- Someone swears that if create-react-app had CSS modules, he would ditch his current setup instantly.
- Someone (me) just wanted decorator support because I’m using MobX in my projects. I know that MobX can be used without decorators, and i know they’re an experimental feature, but the code just looks cleaner and more readable with them.
The create-react-app team clearly stated that it doesn’t plan to add support for any experimental Babel features, or for custom webpack/babel configs. It totally makes sense, and after a few days of exploring the codebase, i completely understand them and support them even more in their decision.
*whispers silently* but devs still want some config options…
So what they do right now to customize their setup is:
- They either eject their app and modify webpack/babel manually (opting to lose future create-react-app and react-scripts support in the feature)
- Fork react-scripts and add support for just the X feature they need
- Use another tool and complain that create-react-app is nice but doesn’t suit their needs
What i wanted to do is to write something that’s a little more flexible, allow different, but simple configurations, be always up to date with the original react-scripts, and (hopefully) satisfy everybody.
So i created custom-react-scripts.
Now with few lines of config you can add that X feature you need without ejecting your create-react-app.
Right now it supports:
- CSS modules
You can turn any of these features on/off, you don’t have to use all of them.
How to use it?
create-react-app my-app — scripts-version custom-react-scripts
After your app is scaffolded just modify the .env file in the root of your project to add/remove certain features that you need.
So for example, if you need only support for CSS modules, add “REACT_APP_CSS_MODULES=true” to the .env file, and you’re good to go. You don’t need to eject the whole project to do that! 🎉
Wait, what? You didn’t know that this is possible, right? 😜 Probably, because it’s not documented yet!
Important notice: you don’t need to change or modify the main create-react-app CLI tool, it can remain as it is. Just point to custom-react-scripts when you’re generating your app.
The benefits of not ejecting are that you’ll get updates to create-react-app and custom-react-scripts in the future by just updating those two dependencies, and your project can remain the same.
Hopefully custom-react-scripts will be useful to you, and it will help you to finally start using create-react-app as a build tool. Help me with the remaining issues, and follow me on Twitter to hear about future updates. Visit kitze.io to learn more about me.
If you, or someone you know is interested in a professional React workshop, check out React Academy.
Disclaimer: custom-react-scripts is not a complete fork of create-react-app. It’s just a fork of react-scripts with simple babel/webpack modifications that can toggle extra features. It’s not touching the original create-react-app code. actually, it’s doing very few and small modifications to it. Right now there isn’t any other way to just fork react-scripts, so the whole repo must be forked. Forking react-scripts as an alternative for ejecting has been supported by the CRA team.
Another important notice: The CRA doesn’t advise using of experimental Babel features because they might not be backwards compatible if the feature doesn’t make the ES spec in the future.