Skip to content
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

Allow user to override webpack.config #1111

Closed
BorisKozo opened this issue Nov 29, 2016 · 8 comments
Closed

Allow user to override webpack.config #1111

BorisKozo opened this issue Nov 29, 2016 · 8 comments

Comments

@BorisKozo
Copy link

Hi,

I would like to add functionality that would allow the user to override certain properties in the webpack.config files.
Basically the idea is that that user may create their own config files in the root directory and when webpack is run it will try to merge the default configuration with the user specified one.
We do something similar in our application for application configuration and it works pretty well.
Is it something you will consider to merge?

@BorisKozo
Copy link
Author

Also issue ID is good for my OCD :D

@gaearon
Copy link
Contributor

gaearon commented Nov 29, 2016

Thanks for the proposal. This has been discussed many times before. We currently don’t intend to allow this, as it impedes our ability to safely move forward with painless upgrades, and opens doors for breakage which is exactly what this project tries to protect users against.

You can read these past discussions:

#99
#145
#460
#481
#1060
#1103

@gaearon gaearon closed this as completed Nov 29, 2016
@BorisKozo
Copy link
Author

Perhaps the quantity of requests for the same feature is a sign for something...

In any case, how do I enable source maps without editing the node_modules?

@gaearon
Copy link
Contributor

gaearon commented Nov 29, 2016

Perhaps the quantity of requests for the same feature is a sign for something...

It’s a sign of people wanting to have the cake and eat it too 😄 .
I’m not surprised it’s being requested.
But then everyone might as well use Webpack directly.

The purpose of this tool is curation, easy upgrades, and a setup that always works.
This is not something we could guarantee if we compromised and allowed direct access to Webpack.

In any case, how do I enable source maps without editing the node_modules?

You could wait for 0.8.0 which will have them enabled. (Support is already in master.)

Same for other changes: if you think something is bad, file an issue, and let’s discuss every specific problem. This way we can fix problems for everyone in the ecosystem using this tool instead of just one user.

@BorisKozo
Copy link
Author

I think that it is a sign of people wanting some degree of customization. Without any customization you are basically saying that everyone are obligated to think the way the coders of the library think. In my experience, while it is a completely valid way of doing things, it may discourage people finding new ways to use your library.

But I guess I can always eject and do whatever I want anyway. It saved me the time for the initial setup so it worked out pretty well for me.

I'll go eat cake now :)

@gaearon
Copy link
Contributor

gaearon commented Nov 29, 2016

Without any customization you are basically saying that everyone are obligated to think the way the coders of the library think.

That’s the value proposition of this tool.

I understand why you want customization, but I’ve also seen enough people burned and confused by customizations that I don’t think it’s healthy to add at this point. Maybe some time later in 2017.

There are also alternatives to ejecting. Check out these articles:

https://medium.com/@shubheksha/tweaking-configuration-for-react-scripts-in-create-react-app-d91e9d03a42f
https://medium.com/@kitze/configure-create-react-app-without-ejecting-d8450e96196a

I hope this helps!

@smmoosavi
Copy link

only 12 line of code will end to all of this discussions: (+some line readme about ejecting or injecting and developer responsibility for what happen after inject and no backward compatibility because webpack configs are internal assets)

packages/react-scripts/scripts/start.js

 +
 +  if(fs.existsSync(paths.webpackConfig)) {
 +    console.log(chalk.yellow('Using modified webpack config!'));
 +    config = require(paths.webpackConfig)(config, false);
 +  }
 +

packages/react-scripts/scripts/build.js

 +
 +  if(fs.existsSync(paths.webpackConfig)) {
 +    console.log(chalk.yellow('WARNING! You are using modified webpack config!'));
 +    config = require(paths.webpackConfig)(config, true);
 +  }
 +

what is problem with create-react-app my-app --scripts-version configurable-react-scripts? [email protected] released 2 day ago. but we must wait for their update. (they last commit is for 18 day ago)

As @gaearon mentioned multiple times there, it's not good idea to extend it. From my point of view, I'm giving you gun, so try not to shot yourself, because probably nobody will help you. When you modify something, be completely sure what you doing! source

Please give us guns. at least I know how to use them. 😎

@gaearon
Copy link
Contributor

gaearon commented Mar 4, 2017

+some line readme about ejecting or injecting and developer responsibility for what happen after inject and no backward compatibility because webpack configs are internal assets

What will happen in practice is once it becomes frictionless, everybody will start doing this, and we’ll end up in the same messy situation all boilerplates are in (hard to upgrade, broken edge cases, updates break more things, no shared willpower to diagnose issues and resolve upstream bugs because everyone’s config is different). And yes, every React beginner will think that their use case is surely special enough to tweak a few lines 😉 .

what is problem with create-react-app my-app --scripts-version configurable-react-scripts? [email protected] released 2 day ago. but we must wait for their update. (they last commit is for 18 day ago)

You could volunteer to help maintain it. With backstroke bot it shouldn’t be a lot of work either. Some friction is intentional for the reasons above. I would like this to be possible, but not too easy. Sorry 😛

@lock lock bot locked and limited conversation to collaborators Jan 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants