Update: Deprecating Personal Config

[mysticatea]

Link to rendered RFC

👉 See also the previous discussion #28.

Summary

This RFC deprecates the personal config that is .eslintrc files on home directory.

Related Issues

• New: Simplify the resolution of third-party plugins/configs/parsers #7
• Update: Personal Config Loads Global-Installed Packages #28
• Personal config (~/.eslintrc) doesn't load global-installed configs/parsers/plugins eslint#11914

[kaicataldo]

This LGTM!

I don't think this has to be tied directly to this RFC, but if we're going to officially take the stance that ESLint should be used locally, I do think it's worth revisiting the topic brought up here. I know some other projects have split out their CLI code into a separate package altogether (webpack-cli and @babel/cli, for example).

[not-an-aardvark]

I think we should aim to support two main use cases:

• Local config file, local installation of shareable configs/plugins
• Config file located somewhere in a different project (loaded using the --config flag), shareable configs/plugins installed relative to that config. Currently this also requires the --resolve-plugins-relative-to flag -- maybe we could make that flag's effect automatic when --config is used.

In other words, whoever maintains top-level ESLint setup should also be in charge of specifying shareable configs/plugins as dependencies. We should encourage users to avoid situations where this is not the case (e.g. external config file with locally-installed plugins) because this can easily lead to problems when a config file or its dependencies need to be updated.

[MikeTaylor]

This RFC is a great reason to stay on ESLint v7.x.

[nbcarey]

This RFC is a great reason to stay on ESLint v7.x.

Or move to a different linter.

[MikeTaylor]

Or move to a different linter.

Oh, interesting — do you have thoughts on any alternatives? I'd had the impression that ESLint was one of that "category killers" that sucked up enough air that it was impossible for any alternative to gain traction. But its opinionatedness in this and related areas does not sit well with me, so I am open to alternatives.

[nbcarey]

Or move to a different linter.

Oh, interesting — do you have thoughts on any alternatives? I'd had the impression that ESLint was one of that "category killers" that sucked up enough air that it was impossible for any alternative to gain traction. But its opinionatedness in this and related areas does not sit well with me, so I am open to alternatives.

Just offhand, there are

• deno_lint, from Ryan Dahl, the creator of Node.js, who created deno, a more secure alternative to Node.js that addresses some issues/shortcomings/defects that he sees in Node. deno_lint is deno's linter.

• JSHint — a less-opinionated fork of D. Crockford's overly opinionated JSLint

• Prettier — rather more opinionated than I like

• RSLint — newish, but looks interesting

• Google's Closure Compiler also support linting Javascript.

[MikeTaylor]

@nbcarey Thank you, really interesting list!

[ljharb]

“more secure” is massively debatable, ftr; and prettier is a small subset of what a linter does.

Projects should be linted, and everyone on a project should be able to use the same linter and config (including “you in the future, perhaps on another machine”). A personal config makes it easy to lose track of things in a project context. The reasons to avoid a personal config apply to every linter, and if you want to override this best practice, you can still do it with eslint, it just requires jumping through more hoops.

[MikeTaylor]

The reasons not to use personal config are not something that the creator of a lint tool can judge on behalf of his or her users.

In my case, I want to use the unix formatter, because it integrates well with Emacs, which is my dev environment. But I don't want to impose that preference on other members of the team, who no doubt use different dev environments. I agree that making personal changes to _what _ a linter checks is bad form; personal changes to how it reports the results is not.