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

✏️Proposal: Allow extension of configurations #4412

Closed
shelldandy opened this issue May 5, 2018 · 6 comments
Closed

✏️Proposal: Allow extension of configurations #4412

shelldandy opened this issue May 5, 2018 · 6 comments

Comments

@shelldandy
Copy link
Contributor

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:

module.exports = {
  devConfig: (config, webpack) => config,
  productionConfig: (config, webpack) => config,
  serverConfig: (config, webpack) => config,
}

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 either devConfig or serverConfig

So now we can do something like:

  // react-scripts/scripts/start.js for example
  // defaultConfig would be the one living on `react-scripts/config/webpack.config.dev.js for example

  const userConfig = path.join(process.cwd(), ('react-scripts.config.js'))
  const hasCustomConfig = existsSync(userConfig) && require(userConfig).devConfig
  const config = hasCustomConfig
    ? require(userConfig).devConfig(defaultConfig, webpack)
    : defaultConfig
  // rest of normal code

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.
❤️

@Dascr32
Copy link

Dascr32 commented Jun 13, 2018

@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.

@shelldandy
Copy link
Contributor Author

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?

@AndyOGo
Copy link

AndyOGo commented Sep 3, 2018

Unfortunately react-app-rewired is not actively maintained 😭
timarney/react-app-rewired#162 (comment)

@Timer
Copy link
Contributor

Timer commented Sep 21, 2018

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.

@Timer Timer closed this as completed Sep 21, 2018
@AndyOGo
Copy link

AndyOGo commented Sep 21, 2018

Hi, why not getting inspired by Next.js success?

@Timer
Copy link
Contributor

Timer commented Sep 22, 2018

Because we're a completely different project (in terms of goals) than Next.js. 😄

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

No branches or pull requests

5 participants