Customizing Create React App: react-scripts vs react-app-rewired vs customize-cra

Create React App (CRA) abstracts away complex build tooling behind react-scripts, offering a streamlined developer experience. But what happens when you need to tweak Webpack, add a Babel plugin, or adjust PostCSS settings? That’s where react-app-rewired and customize-cra come in — though they solve the problem differently, and not all paths are equally sustainable. Let’s break down how these tools work, their trade-offs, and when to use each.

🛠️ Core Roles: What Each Package Actually Does

react-scripts is the official engine behind CRA. It bundles Webpack, Babel, ESLint, Jest, and other tools into a single dependency. You never configure these directly — everything is hidden behind abstraction.

// package.json (standard CRA)
"scripts": {
  "start": "react-scripts start",
  "build": "react-scripts build"
}

react-app-rewired replaces react-scripts in your npm scripts and injects a custom configuration file (config-overrides.js) before CRA’s internal config runs. It patches the Webpack and Jest configs at runtime without ejecting.

// package.json (with rewired)
"scripts": {
  "start": "react-app-rewired start",
  "build": "react-app-rewired build"
}

customize-cra is not a standalone tool. It’s a library of helper functions meant to be used inside config-overrides.js when you’re already using react-app-rewired. It simplifies common overrides with readable APIs.

// config-overrides.js
const { override, addWebpackAlias } = require('customize-cra');

module.exports = override(
  addWebpackAlias({ '@': path.resolve(__dirname, 'src') })
);

⚠️ Critical Note: As of 2024, both react-app-rewired and customize-cra are effectively unmaintained. The react-app-rewired GitHub repository states: “This project is in maintenance mode... it may break with future versions of react-scripts.” Similarly, customize-cra hasn’t seen meaningful updates since 2021. Do not use them in new projects.

🔧 Common Customization: Adding a Webpack Alias

Let’s compare how each approach handles a typical request: aliasing src to @.

With react-scripts (No Customization)

You can’t do this. CRA doesn’t expose Webpack config. Your only options are:

• Use relative paths (../../../components/Button)
• Or eject (which copies all config into your project permanently)

// No solution without ejecting or third-party tools
import Button from '../../../components/Button'; // verbose

With react-app-rewired (Manual Override)

You write raw Webpack manipulation code in config-overrides.js.

// config-overrides.js
const path = require('path');

module.exports = function override(config) {
  config.resolve.alias = {
    ...config.resolve.alias,
    '@': path.resolve(__dirname, 'src')
  };
  return config;
};

Now you can import cleanly:

import Button from '@/components/Button';

With customize-cra (Declarative Helper)

You use a helper function to avoid touching Webpack internals directly.

// config-overrides.js
const { override, addWebpackAlias } = require('customize-cra');
const path = require('path');

module.exports = override(
  addWebpackAlias({
    '@': path.resolve(__dirname, 'src')
  })
);

Same result, but less error-prone if you’re unfamiliar with Webpack’s structure.

🧪 Adding a Babel Plugin

Suppose you want to use babel-plugin-styled-components for better debugging.

react-scripts

Not possible without ejecting.

react-app-rewired

You must manually merge into the Babel config:

// config-overrides.js
module.exports = function override(config, env) {
  // Find the Babel loader rule
  const babelLoader = config.module.rules.find(
    rule => rule.loader && rule.loader.includes('babel-loader')
  );
  if (babelLoader) {
    babelLoader.options.plugins = [
      ...(babelLoader.options.plugins || []),
      'babel-plugin-styled-components'
    ];
  }
  return config;
};

customize-cra

Use the built-in addBabelPlugin helper:

// config-overrides.js
const { override, addBabelPlugin } = require('customize-cra');

module.exports = override(
  addBabelPlugin('babel-plugin-styled-components')
);

Again, customize-cra reduces boilerplate — but only if the helper exists for your use case.

⚠️ Fragility and Maintenance Risks

All customization via react-app-rewired or customize-cra depends on CRA’s internal config structure remaining stable. When CRA updates react-scripts, your overrides can silently break because:

• Rule names or loader structures change
• New optimization passes interfere with your modifications
• Environment-specific configs diverge (e.g., dev vs prod)

For example, CRA v5 introduced significant Webpack 5 changes. Many react-app-rewired setups broke because overrides assumed Webpack 4 patterns.

There’s no compile-time check — your app might build successfully but behave incorrectly at runtime (e.g., missing CSS, broken HMR).

🔄 Realistic Upgrade Path

If you’re maintaining a legacy CRA app that already uses react-app-rewired, proceed cautiously:

1. Pin react-scripts to a known-working version in package.json
2. Test thoroughly after any dependency update
3. Plan a migration to a more flexible build system (e.g., Vite, Remix, or vanilla Webpack)

For new projects, do not start with react-app-rewired. Instead:

• If you need light customization: use CRACO (though also minimally maintained)
• If you need serious control: choose Vite + React or Next.js, which offer first-class config extensibility

📊 Summary Table

💡 Final Recommendation

• Stick with react-scripts if you can live within CRA’s boundaries. It’s stable, secure, and officially supported.
• Avoid react-app-rewired and customize-cra in new codebases. Their maintenance status and fragility make them technical debt traps.
• Migrate away if you’re already using them. Modern alternatives like Vite offer faster builds, better TypeScript support, and explicit config files — without the risk of breaking on every minor update.

The original promise of CRA was “no configuration needed.” If you’ve outgrown that, it’s time to graduate to a tool that embraces configurability rather than fighting against it.