escape hatch

[acornejo]

any thoughts about adding an escape hatch that allows users to do minor tweaks to the eslint or babel preferences without actually ejecting?

it is a shame to eject to change a dangling comma linting preferences or to add a babel plugin to use relay (I am not looking for solutions for these two specific cases, these are both hypothetical examples).

the create-react-app philosophy of providing opinionated and sane defaults is what makes it great, and its impossible to cater to everyone's desires and preferences. but perhaps there is some room for improvement, and adding a simple mechanism to do simple tweaks, displaying a warning that makes it clear customized settings are unsupported and won't upgrade cleanly, would go a long way.

[gaearon]

The linting use case is not very clear to me. We don't include any stylistic rules on purpose so people don't argue over them. We only include rules that usually indicate actual mistakes, not style. If you see an annoying rule with false positives please file issues.

This has been discussed many times before. If you search for "plugin" in the issues you will find 5 or 6 discussions where I explained why I would rather not add these options at this point in the project. I realize we can't make everyone happy, but we're not trying to. No configuration gives us real leverage (being able to add and remove plugins without breaking people configs, safely updating any versions without introducing incompatibilities, excluding experimental plugins that we know to be unstable and that, when they break, people blame React for, etc). You might be better served by alternatives such as nwb if you don't agree with this philosophy.

[gaearon]

displaying a warning that makes it clear customized settings are unsupported and won't upgrade cleanly, would go a long way.

This is going to introduce massive problems because people like shiny things and will massively abuse these options. Then tools will break, like they used to, but we wouldn't be able to fix them because we don't have control over complete experience anymore. This defeats the point of the project which is to provide a setup that just works.

[acornejo]

thanks or the prompt reply! the case for linting it was not so much to remove rules, but to add new ones to enforce certain styles.

I did see plenty of discussions about babel plugins but most of them seemed centered about adding a specific plugin (most often decorators) instead of adding a mechanism that allows users to add arbitrary plugins.

in any case, I got my answer, and it makes sense, this narrows the target audience and that is ok.

in my experience its hard to have more than 1 developer collaborating on something without adding style-based linting (i.e. enforcing semicolons, tabs vs spaces, etc), and similarly using other babel-plugins can be indispensable for some tools (relay, etc). These are both things you can always do without (linting is a niceity and so is babel, since you can always do the transpiling by hand if you want).

[gaearon]

I can see the value in enforcing style but I don't think lint warnings are a great way to do this. Ideally the person would just pick a style, and if there is a violation, there is an interactive prompt saying something like "Do you want to autofix the style issues?". ESLint already includes autofix functionality for many rules so we could figure out a way to do this if somebody is willing to invest time into a proof of concept.

I also don't see why you can't have a separate tool (like standard) that enforces style. It doesn't even matter if it uses ESLint or not.

We might someday explore allowing Babel plugins but today is not that day. For now we're happy to explore doing library-specific integrations by hand (like Relay) if there is enough community interest in them.