✏️Proposal: Allow extension of configurations

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

[AndyOGo]

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

[shelldandy]

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?