Support ESLint configure or disabling ESLint (discussion)

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

As continuation of my comment from #3815

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 , #2863

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 Related issue for allow custom config: #2318

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

[nfantone]

@oriSomething @gaearon Adding to the list:

• Not being able to integrate Prettier with ESLint.
• Having potentially different IDE / in-browser rules hurts developer experience.
• Locking eslint + plugin versions force users to wait on next release for bug fixes.
• Not being able to define a custom "lint" script to check for rules on CI jobs, such as "lint": "eslint src/**/*.js", even if it’s only using default CRA setup (ie.: "extends": "react-app")

❯ yarn lint
yarn run v1.3.2
$ eslint src/**/*.js
Cannot find module 'eslint-config-react-app'
Referenced from: /dev/my-project/.eslintrc.json
Error: Cannot find module 'eslint-config-react-app'
Referenced from: /dev/my-project/.eslintrc.json
    at ModuleResolver.resolve (/dev/my-project/node_modules/eslint/lib/util/module-resolver.js:74:19)
...
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Manually adding eslint-config-react-app to your dependencies leads to myriad of other problems + goes against the very philosophy of this project. Related: https://github.com/facebook/create-react-app/issues/3998

---

Proposal

• Make eslint usage opt-in, but strongly recommended. Perhaps a "peerDependency"?
  • Or, make create-react-app generate the actual needed boilerplate to emulate current behaviour without hiding the configuration (i.e.: write a .eslintrc file on root + install and declare deps ala eject).
• Let users extend configuration with whatever they (or their organizations) need/use.
• Let users handle lint + plugins dependency versions.
• Lint code during build/serving using local .eslintrc file.

---

The way I see it, enforcing “zero config” concepts on such opinionated/versatile tools like linters only harms the experience create-react-app is trying to provide. What’s the real benefit with the current approach anyway? This is not a core component of the build pipeline. Locking versions and obscuring the works of trivial -but important- tasks like linters feels needlessly constricted, with very little trade-offs. IMHO, it’s only there to save me from installing a bunch of dependencies and writing a configuration file. But writing the config (or rather, the need to do so) is what this issue is all about and the installation happens anyway. Both things can be greatly simplified by allowing create-react-app to output a suggested initial scaffolding.

[silverwind]

So here is what I think CRA should do:

• install eslint and eslint-config-react-app as a direct dependencies.
• create a .eslintrc.js in the project root with just extends: eslint-config-react-app.
• point webpack to above file. If it doesn’t exist, use eslint-config-react-app.
• enable normal usage of .eslintignore in webpack (https://github.com/facebook/create-react-app/issues/2339).

This should make everyone happy. Users get to extend the configuration and can install plugins and webpack and CLI/Editor linting are ran with this same linting configuration.