-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add feature additional configuration webpack and Babel without eject #1103
Conversation
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 cla@fb.com. 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 cla@fb.com if you have any questions. |
eslint.configFile must be relative path of project.
would love this feature! great work! let's hope for merge :) |
@bigslycat curious what specifically would you be looking to add to the configs. Plugins etc... |
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! |
@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 I know that I can just run @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. |
Sry, I was forced. If someone else would use the package, please notify me about errors in the README and sorry for my English. =) |
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. |
@gaearon The fact of the matter is that after I tried |
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. |
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. |
Replace Babel or webpack configs in
build
andstart
scripts without eject. Usage examples: