Support ESLint configure or disabling ESLint (discussion)

Created by: oriSomething

Sorry for removing the Github template, it was irrelevant. Anyway:

As continuation of my comment from #3815 (closed)

I know this issue discussed in the past in many different issues, and yet, I think we should revisit the support of custom ESLint config by user or at least the ability to remove it so we can use our configuration or even in cases where users don't feel they need ESLint.

Good part with current state

Most of the configuration is good.
Config is config is config. If there is something the user can configure. It might break in future versions.

Pain points with current state

Currently the only option to really control the configuration of ESLint is by eject or by fork. In both cases we lose the charm of using react-scripts which makes most things to be more convenient and tools that are updated automagically between versions of packages such as webpack end ESLint as well.

But lack of controlling the configuration can cause a lot more issues, which makes the ESLint part in create-react-app to be a pain for development.

The eslint-config-react-app does contains stylistic rules, even tough they're not from the "prettier" kind. For example: default-case rule forces me to put empty default: case even when it's an empty and unneeded, since in my project the convention it to do the "default" after the "switch-case block" or in cases when default is really unneeded. It's easy to say just add /* eslint-ignore default-case */, but it becoming more of a "file template" than some exception that happens "here and there". Moreover, even most consensus rules such as eqeqeq might not feet to any project, and will be more of stylistic choice rather than the right one. For example, I worked on a project where I've used Flow and have a lot of cases where == was more than a necessary to make code readable, since when you're type is string | null | undefined and you need to make lots of compares things like a == b was much better than a === b || (a == null && b == null) (I've simplified the "If statement"). Flow can make sure it's not number compared to string (And I know, it's an edge case, but it was only for a demonstration).

Plugins are very useful, but when I can't config, it means no real use of plugins. Because, on the browser I'll have one configuration and on then IDE / CLI I'll have other configuration, which is a pain. There some cases you'll need to remove some ESLint rule because some plugin gives you a better rule which might conflict with the original rule. But you can't configure, so warnings / errors in the browser will be leave you with conflicts. And The actual use of plugins is discourage since, as I said before, I'll get in the browser different result from what happens in the IDE / CLI. Half related issue: #1345 (Why should I need to wait to the support or be forced to the plugin if I don't need?)

Globals are also a big issue, If you forced to use third party code from a CDN it means you'll have a lot of /* globals myAwesomeGlobal */ in your files. And please don't tell me to use window or global, It's a temporary work around not a solution. In many cases when I'll want to remove the "global" since we stop to use some third party service, I won't have an easy way to know it "truly happens". When I'm not the only one who work on the project. Using window or global will only make it harder. Moreover, as browsers become more and more modern and some script will start use global as let or const the variable won't exist on the window object (not to mention when a file should run also inside Worker / Node which only makes things more complicated for using globals). Moreover, there are libraries such as Modernizr 3.0 that force me to generate a file to src folder, that generated automatically. If I'll add it to public it will force another network request call and If I put it in src it forces me to add manually /* eslint-disable */ or start creating boilerplate scripts for this kind of code injection. Relates issue: #2339 (closed) , #2863 (closed)

Don't get me wrong, I fully understand the project philosophy and admire the work that have been done. But, on the other hand you lock me with this project "configuration" for a linter with specific rules which makes it harder work for me than not having the linter from the first place. Since there is no easy way to opt-out without ejecting/forking, it makes it harder as more conflicts with the eslint-config-react-app happens during project life time. Moreover, you actually do have configurations such as "homepage". Even if it's not much. ESLint is one of the biggest pain points for me in the create-react-app suite.

Suggestion

My suggestion is to allow custom configure or at least to disable ESLint project wide.

Related issue for disable ESLint: #2157 (closed) Related issue for allow custom config: #2318 (closed)

P.S. I can find more related issues to every issue I've wrote here, but I don't think it gives any value.