Add feature additional configuration webpack and Babel without eject

[bigslycat]

Replace Babel or webpack configs in build and start scripts without eject. Usage examples:

BABEL_REPLACE=.custom.babelrc react-scripts start

WEBPACK_REPLACE=custom-webpack-config.js react-scripts start
WEBPACK_MERGE=custom-webpack-config.js react-scripts start

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks!

If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact [email protected] if you have any questions.

[themre]

would love this feature! great work! let's hope for merge :)

[timarney]

@bigslycat curious what specifically would you be looking to add to the configs. Plugins etc...

[gaearon]

Thanks for the PR but we won’t be building abstractions on top of Webpack configs, nor allowing to directly manipulate them. This has been proposed many times before so I will refer you to older threads, such as #99 and #167.

This lets us easily make big changes to configuration, update or revert updates to underlying tool versions (e.g. Webpack 2 soon) without breaking compatibility, and saves users from mistakes in configuration like https://github.com/cssinjs/react-jss/issues/32#issuecomment-190819245.

As mentioned in #99, please file issues about specific use cases you need plugins for so that we can decide on a case by case basis. Thank you for your time!

[bigslycat]

@timarney this depends on the stack. In one case I want to support older browsers, otherwise I do not want anything to support (a real stack for my current employer's Intranet project). I want a custom configuration eslint with blackjack and I desired plugins. I use less-loader and any other loader.

I know that I can just run eject script or write my configuration with .... BUT at the same time, I want to be able to use the experience of community — precisely because of this I use this package.

@gaearon but is it for this we use semver? Daylight Webpack 2 will mean increment a major version of create-react-app. This is the normal approach.

[bigslycat]

Sry, I was forced. If someone else would use the package, please notify me about errors in the README and sorry for my English. =)

[gaearon]

@gaearon but is it for this we use semver? Daylight Webpack 2 will mean increment a major version of create-react-app. This is the normal approach.

Semver doesn't solve the pain of updating, it just prevents breakage. Opening this up will just mean things will keep randomly break as you bump versions of CRA. This is especially bad for beginners who will clone examples, try to update something, and then get errors they can't debug. This is the typical "JavaScript fatigue" everyone has been talking about.

I understand your frustration, but you are more of a power user than most people getting started with React or frontend development. If you are comfortable with setting up Webpack and Babel by yourself and trust yourself to not make mistakes, this project might be too basic for you, and I encourage you to look at alternatives listed in our README, or to maintain a fork.

[bigslycat]

@gaearon The fact of the matter is that after I tried create-react-app, I do not want to use any other. =) This is a very good solution to the problem encapsulate routine configuration and best practices of the community for building of the low-level application architecture. I really want to continue to use this experience. But at the same time I want to leave at my stack. What should I do? =) I am ready to maintain the fork. From it will depend on several corporate projects, so his fate will be quite safe. But I think it's not the most elegant solution. I think there is a possibility of a compromise. We just need to take care of beginners.

[gaearon]

For ESLint, nothing prevents you from using your own config and running as a separate step. Integrated lint would still use our default rules, but you could add your own lint config as a precommit hook.

For Less, you can already use it without ejecting by using its Node watcher rather than a Webpack loader. See #1008 for a similar example.

For anything else, raise issues about particular use cases. E.g. you need a specific plugin because (describe the use case). This will help me understand the motivations and hopefully address some of these requests in future releases.

And as a last measure, yes, you could fork it (I don't think it's a too bad solution to be honest). There are also experiments like custom-react-scripts and react-app-rewired which you could use or compel to implement this feature instead of maintaining your own fork.

[nk2580]

For those who are interested, there might be a way to “fake” plugins for CRA. The workaround for SASS is a great example. Any extra transpiling or processing should be done before the build action in the npm scripts. That way the bundling is completely untouched and simply imports on the result of your custom actions if needed, if not and it’s static output then it should go in the public dir anyway. Anything beyond this and you’re changing how you bundle the app. Which means you should definitely eject.