Allow webpack configuration customizations without ejecting

[lewisdiamond]

Ejecting has a huge cost, you lose all further updates. Yet, CRA doesn't necessarily allow you to setup your app the way you want. For example, I use stage-0, decorators and sass-loader w/ modules.

I ended up creating my own fork to allow me to easily tweak the configuration without ejecting. But now I have to maintain my own fork. (details on how it's done: here)

I understand that you guys don't want to be "tied" to webpack by having users tweak configuration:

The feature set is intentionally limited. It doesn’t support advanced features such as server rendering or CSS modules. The tool is also non-configurable because it is hard to provide a cohesive experience and easy updates across a set of tools when the user can tweak anything.

But customization could be made easier while remaining unsupported.

If I create a pull request with a .env variable to define the dev/prod customization filenames, using the same setup as I did in my fork, is there any chance that the pull request would be accepted?

[gaearon]

What plugins in stage-0 do you find useful? Decorators will eventually be supported (when spec advances and Babel officially supports plugin for it).

[lewisdiamond]

I don't use stage-0 for actual stage-0 features anymore, most of what I use is now in stage-2 but I've set stage-0 from the start (some features were in stage-0 back then iirc).

Still, the point is that different project will require different tweaks and as soon as it falls outside of what's supported, you have to eject, which is very costly.

[gaearon]

I understand your point. This has been discussed very many times, I encourage you to search for past discussions. We are looking to expand our default feature set without adding configurability, and so far we've been able to do that. I'd like to learn more about features blocking you from dropping custom config (is it just decorators?) You can use SASS (it is documented), and some stage 2 features that we deem stable are already supported. What's the deal breaker for you?

[lewisdiamond]

Off the top of my head, those I remember are the following:

• Decorators
• Async/await
• Object rest/spread
• Class properties (static and non static)
• CSS Modules

Some of them are supported now, which is nice, but decorators and css modules are not (more specifically, I use sass + modules)

And yesterday I had to override eslint rules that broke my build because of class properties (and a bug in eslint). I didn't really spend too much time finding a better solution though, I only tried .eslintrc which didnt work.

[gaearon]

Some of them are supported now

Not just some, but most of the features (object rest/spread, async/await, class properties) you are quoting have been supported since the very first releases. Did something give you another impression? We documented supported features in User Guide but I'm not sure if something else implies they're not.

Decorators will be supported when there's a stable Babel plugin implementing latest spec.

CSS Modules are under consideration.

So it looks like your demands will be satisfied with default setup some time this year.

As for ESLint bug please file such issues with us rather than try to override configuration. Otherwise we can't guess something is broken, and it stays broken. Class properties are meant to be fully supported so if some underlying tool breaks we want to know so we can follow up and add an integration test for the future.

I'll close this issue (we don't plan configurability in near term) but please file new issues for any bugs you discover, as well as for specific feature requests (unless an issue already exists).

Thanks!

[lewisdiamond]

Did something give you another impression?

Not really, it was a long time ago I just did not recall the details.

[gaearon]

For anyone reading this in the future, I would like to point out that the decorators spec has changed significantly. I'm really glad we made the decision to not support them at early stage, so users who didn't eject don't need to change their code.

I don't recommend anyone to rely on the legacy decorator transform (that is not part of CRA). See this thread for more info: https://twitter.com/dan_abramov/status/897491076537356288.

[TheTFo]

I can still see something like this being useful. For example, there has been hot debates over which source map settings to use. Would be cool to be able inject your own.