Great question—this is something almost every React developer using CRA grapples with at some point. Let’s break down what eject does, its downsides, impacts on your project, and better alternatives.

What does npm run eject actually do? #

When you run npm run eject, you’re essentially "breaking out" of CRA’s encapsulated configuration layer. CRA hides all the complex webpack, Babel, ESLint, and other build tooling behind the scenes to keep your project clean. Eject copies all those hidden configuration files (like webpack.config.js, babel.config.js) and moves all internal dependencies (previously managed by CRA) into your project’s package.json.

Downsides & Impacts of Ejecting #

Let’s tackle your specific concerns:

1. Loss of official CRA updates #

The biggest downside is that you’ll no longer receive automatic updates from the CRA team. Any future patches, performance improvements, or new features (like webpack 5 upgrades, better tree-shaking, or new Babel plugins) will require you to manually update your configuration files. This is error-prone and can lead to compatibility issues if you’re not familiar with all the underlying tools.

2. Bloated package.json #

As you mentioned, ejecting dumps dozens of internal dependencies (think webpack, babel-loader, eslint-config-react-app, etc.) into your devDependencies. This makes your package.json much longer, and you’re now responsible for managing version conflicts between all these packages—something CRA handled seamlessly before.

3. Project size & load speed (mostly indirect) #

Ejecting itself won’t directly increase your production bundle size or slow down load times. The default production configuration after eject is identical to what CRA uses. However, if you start modifying the configuration incorrectly (e.g., disabling tree-shaking, skipping code splitting, or adding unoptimized plugins), you could end up with larger bundles and slower loads. If you leave the config untouched, though, your build output stays the same.

4. Reduced maintainability #

CRA’s default configuration is battle-tested and optimized for most React projects. After ejecting, you’re stuck maintaining a full set of build tooling configs. This adds overhead: new team members might not be familiar with webpack/Babel intricacies, and debugging build issues becomes more complex. For small to medium projects, this extra maintenance is almost always unnecessary.

Alternatives to Ejecting #

You rarely need to eject—here are better options for customizing your CRA project:

• Use craco (Create React App Configuration Override)
  This is the most popular tool for modifying CRA config without ejecting. Create a craco.config.js file in your root directory, and you can override webpack, Babel, ESLint, and more. It keeps your project aligned with CRA updates while letting you tweak settings as needed.

• react-app-rewired
  An older but still viable alternative to craco. It works similarly by letting you override config via a config-overrides.js file. Craco is generally recommended now since it’s more actively maintained.

• Switch to Vite (for new projects)
  If you’re starting a fresh project, Vite is a far faster alternative to CRA. It has built-in support for React, offers instant hot module replacement, and lets you customize its configuration directly without any eject-like steps. Build times are drastically faster, and the config is more intuitive.

• Leverage CRA’s built-in features first
  Before reaching for eject, check if CRA already supports what you need. It has built-in support for:

  • CSS Modules, Sass, and PostCSS
  • Environment variables via .env files
  • Code splitting with React.lazy and Suspense
  • Custom ESLint rules (via extending eslint-config-react-app)
    Most common customization needs can be met without touching the underlying build config.

内容的提问来源于stack exchange，提问作者Shashank Dave