-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
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
✏️Proposal: Allow extension of configurations #4412
Comments
@shelldandy have you checked react-app-rewired? It lets you modify your configurations without ejecting. I've been using it for a while and works fine. |
Yeah I use that as well quite often (I'm using it right now), but then again wouldn't it be much better to have that "composability" from a first-party source? |
Unfortunately |
Hi! Thanks for this suggestion, but we're not quite ready to open Create React App for configuration. There's too much active churn in the community/tooling still. |
Hi, why not getting inspired by Next.js success? |
Because we're a completely different project (in terms of goals) than Next.js. 😄 |
Hey there! I was recently thinking about a way to keep cra zero-config to begin with but also allow it to grow/override if/when needed (css-modules, typescript, lqip, etc etc)
My proposal would be to have a file at root level called
react-scripts.config.js
in which the template would look a bit like this:In all of those cases they would take a function with the first argument being the opinionated config from cra and a second optional argument which would be the same webpack used for whatever script being used (for plugins or whatever)
So now the user can tweak that config or even make another one remembering that in the end he has to return a config object for webpack to consume.
Now on the scripts code we can run
fs.existsFileSync
to check for that file and then to check if the object has that prop which we care for depending on the case. Eg. on start script check for eitherdevConfig
orserverConfig
So now we can do something like:
This would make it still be zero-config, but extendable. That way users don't have to choose between no freedom or all the freedom, but rather get the right amount of freedom without losing on updates or forking the package.
Does this has potential? lmk and i could work on a PR to make this happen i don't think its a really big change on the codebase to achieve.
Cheers and thanks to everyone for this awesome package.
❤️
The text was updated successfully, but these errors were encountered: