Update: Personal Config Loads Global-Installed Packages

[mysticatea]

open Rendered RFC

Summary

This RFC allows the personal config to load also global-installed packages (shareable configs, parsers, and plugins).

Related Issues

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

[ljharb]

I think this is a bad idea - eslint shouldn’t be encouraging anything to be installed globally, and having a personal config imo is also a bad practice. If a project doesn’t have eslint configured, eslint shouldn’t be run on it.

[kaicataldo]

I agree with @ljharb's concern about encouraging the use of global installation. That being said, we do currently support the use case of having a personal config in the user's home directory, and this does seem like it would help those who use it out.

I know we've hashed this out a lot over the years, but I wonder it it would be worth digging into this discussion again (though it doesn't have to be in this RFC!). I wonder if we could avoid a lot of confusion if we just didn't support running ESLint globally (showing a helpful error message letting the user know they should install locally) and instead offered something like eslint-cli for those who really need a globally accessible eslint in their PATH. That way, eslint would always be running locally per project - it's just being invoked through different means.

[not-an-aardvark]

I don't think we should do this. The idea of a "global installation" isn't well-defined by Node -- it's something defined by npm that doesn't always exist for other package managers. I think we should avoid any kind of "magic" that tries to make guesses about the user's package management strategy.

I also agree with @ljharb that we shouldn't encourage the use of global installations/home-directory configs.

[platinumazure]

Yes-- I would prefer we either have personal configs resolve from CWD, leave them as they are, or remove support for personal configs entirely in 7.0.

[mysticatea]

I agree with the personal config is a bad practice. But it's supported now.

The problem that this RFC wants to resolve is that people have to install dependencies into their home directory when they use the existing personal config functionality.

My position is that it's pretty worse than global installation. Because people have often had their project directories in their home directory, so those projects can load the packages in the home directory in mistakes.

This problem was not in ESLint 5 and older.

I strongly don't want to encourage to install dependencies into the home directory instead of global installation.

[aladdin-add]

is personal config documented somewhere? if yes, we might have to fix it in eslint v6, and give user a warning so we can remove it in eslint v7/v8.

[not-an-aardvark]

I agree with the personal config is a bad practice. But it's supported now.

The problem that this RFC wants to resolve is that people have to install dependencies into their home directory when they use the existing personal config functionality.

My position is that it's pretty worse than global installation. Because people have often had their project directories in their home directory, so those projects can load the packages in the home directory in mistakes.

I agree that this isn't ideal. However, I don't think the solution is worthwhile.

• This same problem exists for any other Node files in the user's home directory -- if I have a file in ~/foo.js that calls require("lodash"), then installing lodash can cause the lodash installation to be reachable for other projects. This is a disadvantage of the home directory in general -- it's difficult to manage dependencies
• Conceptually, there isn't any link between home directories and global installations. A "global installation" just means that a package is installed in a special folder known to the npm client, which is also added to the user's $PATH. It's not intended for dependencies of files in the filesystem.

It seems like the reasoning for this RFC boils down to saying, "It's inconvenient to manage dependencies for files in a home directory, so we should unilaterally designate another folder to install dependencies of those files instead". But this could end up being confusing, because it would no longer be the case that shareable configs are loaded the same way as calling require from the config that loads them. Since home-directory configs always have dependency management problems, I'm not sure it's necessary for us to solve them here when users have better alternatives anyway.

Personally, I would rather deprecate home-directory configs instead and keep encouraging people to use local installations. Home-directory configs can seem convenient at first, but they cause confusion when working on projects with other people.

is personal config documented somewhere? if yes, we might have to fix it in eslint v6, and give user a warning so we can remove it in eslint v7/v8.

Personal configs are documented. However, this proposal isn't a bugfix -- it's an additional feature to try to improve the ergonomics of personal configs. So I don't think we have to fix it in ESLint v6.

[webOS101]

It would be a real shame to lose home level (personal?) configs. Having this means that I can lint any JS file on my computer, regardless of whether it's part of an npm-managed repo or not. Not every use of eslint should have to be part of an npm (or yarn, or some other package-manager) project.

[ljharb]

I'd disagree; I think that all code should be in a project, and that if the project doesn't lint the files, they should not be linted at all.

[webOS101]

Perhaps the tagline on the web site should be updated:

ESLint
The pluggable linting utility for JavaScript and JSX inside of npm projects

Every legacy website without bundling tools and package.json files will be cut-off.

[ljharb]

Sounds good to me, since all they have to do is add a package.json instead of just magically hoping all the projects developers use the same versions of everything :-)

[webOS101]

Not everyone works on a team of developers.

[ljharb]

Sure they do - a team of 1 is still you, and "you in 6 months".

[mysticatea]

OK. We, the ESLint team, look to have the consensus that we should deprecate the personal config. Therefore, I will make the RFC that deprecates the personal config rather than I continue to champion this change.

[brettz9]

I'm a bit late to the party and haven't used personal configs previously.

While it is clearly a good practice for projects to have their own local configs, the idea that a project-level config is always sufficient is mistaken.

There are two perfectly valid reasons:

1. Sometimes project owners, despite having a useful project, are lazy or, on the other hand, are minimalist (yes, even for devDeps) in what they want added (especially for smaller projects).* (One maintainer doesn't want to add devDeps, relying only on the standard CLI, knowing it makes it more challenging for development, e.g., with IDE use, but he says he doesn't want to intimidate new developers.) These maintainers, however, are not opposed to fixes that may be inspired by eslint, but they are opposed to adding additional configs themselves. While there is indeed still --config, unless multiple can be applied, one would need a separate config for each project--so as to be able to import one's global config and import the local config (in case the local config has its own project-specific requirements).
2. I am interested in exploring the linting of dependencies for the sake of better security (and transparency to their consumers as to what privileges are required). Rules like import/no-nodejs-modules (with the allow set to include presumably safe modules like path but not allowing fs, http, etc.), rules like no-eval, no-global-assign (or the proposal and discussion for preventing assignment or even reading from certain global properties), could help provide an additional measure of security, as one might not care where a third party dependency puts their curly brackets, but they do want to know if there are unsafe or high-privileged practices being used in it. It might not be as foolproof as Deno may be (in disallowing certain operations unless a flag is passed), but if the linting rules are well-designed and don't allow for virtually-impossible-to-track syntax like eval, then it may at least help make Node dependency usage more safe.

For the latter use case, there is one additional challenge, but I think it is worth implementing (as a plugin if not in core):

• The ability to lint through all files which are imported or required in the targeted root file(s)--since one need not lint third-party dependencies in their entirety--just the files one is actually using (and if the linting is robust enough to detect all manner of importing). (There are tools like https://github.com/TrySound/rollup-plugin-eslint/ , but this doesn't appear to work out of the box for doing linting alone.) For security reasons, one would presumably like to ensure that any extension that were required/imported were linted, not just whatever --ext were passed in. I'd think this wouldn't be too hard to implement by using resolve and esquery.

* Further background

While I tend to favor rigorous configs, but not all maintainers will bother themselves or their devs to use adopt one (e.g., my https://github.com/brettz9/eslint-config-ash-nazg borrows from various configs, but it has a whole lot of peer deps. to install; there is install-peerdeps, but not everyone will want want to allow this, especially for smaller projects).

Then there is the question of settling on a config to use; on one project, a maintainer insists on using his config, while allowing for suggestions of useful rules to be added to it; however, even for projects which are open like this, it is not practical for me to spend time like this on submitting rules to each config project when I feel my own config is already attempting to be most rigorous (it would be more suitable if I get around to setting apart its stylistic-only rules so I wouldn't need to impose my style preferences everywhere).

[ljharb]

(non collaborator, personal opinion) Laziness isn’t a motivation, and if some maintainers don’t want eslint as part of their project, that project shouldn’t be linted. It’s not doing the project any favors to provide it with linting-inspired fixes without actually providing it with linting. In other words, i think everyone in a project should be forced to use the same lowest common denominator, which in your example is “no linting”. If that causes bugs, good - it’s persuasive evidence to lint :-)

It seems like your second example falls in the same bucket for me - your rigor should be limited by the rigor all project developers enjoy.

[brettz9]

Thank you for your reply, @ljharb. I'm going to use a pretty dramatic example to respond to this as I think it fits, but let me first say at the outset that I really appreciate all of the hard (and otherwise highly intelligent!) work contributors as yourself have offered to bring eslint and other projects in the community that is really as essential as a public utility is to a community.

I really hope the hyperbolic (and hopefully not too lengthy) analogy that follows is offered in the interest of a clash of opinions bringing forth a spark of truth rather than in any intent for a personal clash. Now on to the hairy parts... :)

if some maintainers don’t want eslint as part of their project, that project shouldn’t be linted. It’s not doing the project any favors to provide it with linting-inspired fixes without actually providing it with linting. In other words, i think everyone in a project should be forced to use the same lowest common denominator, which in your example is “no linting”. If that causes bugs, good - it’s persuasive evidence to lint :-)

To me, this is really quite a bit like saying that if a head of household refuses to purchase a low-cost, government-funded health check for his family, a health check that can catch problems early, that an independent doctor (whether working for pay or charity) should not provide medical services to a family that had refused such services in order that the family learns their lesson. Nevermind the legitimate reasons the parent may have felt they had in spending their money elsewhere, nevermind the innocent children (i.e., the library's direct consumers), nevermind the extra spread of disease within the community (i.e., the users of the library and its dependents who suffer from its bugs), let's let everyone get crucified for our Social Darwinian ideals of people getting what they deserve!

Bugs of course have real world consequences, including for security and livelihood. If independent doctors want to use the medical instruments, however developed with the intent of being used as part of regular health checks, and especially if such use comes at no cost to the government which funds the medical technology development (i.e., it doesn't hurt you too much as maintainers to keep the feature), why should doctors be prevented from doing so and their patients be forced to go entirely without medical service?

As a humble "traveling physician" myself, let me explain how your providing me the tools you have developed not only help me to provide my patients with however palliative fixes or treatment (sometimes which fix a problem for a long time allowing much good to come as a result), but I have seen first hand on a number of occasions the ability to freely use and offer your tools to such patients can actually encourage these patients to sign up to your preventative healthcare health checks when they would not have done so otherwise. When I can provide proof-in-hand that with my use of your health checks, I have found actual health problems, the patient may be sobered enough to realize that they really ought to be investing in their own health by doing timely checks, and as a result, their code improves into the future for me and other consumers. Such families as this may survive as they otherwise would not, as I am not capable of so rigorously checking their health with the limited tools of my eyesight alone.

Adding rigorous timely health checks won't ensure we catch all problems, and adopting health checks won't lead in all cases to illnesses being discovered (i.e., the patient may pay some cost at no apparent benefit to themselves, spending time to set up the linting without finding any future bugs). But I agree it is indeed wise for them to have these checks. However, it is only human, albeit unwise, that some will wait until there are some pain points to take care of themselves. But we don't need to resign ourselves to allowing a family see a family member die just to help them see the wisdom of our approach.

Even one who is Darwinian in their world view should be able to see that not everyone who happens to be unwise about health checks is incompetent and of no use to society in other ways. There are many great tools even developed by geniuses yet who fail to fully take care of their health, and a concerned neighborly physician could restore them, thereby also allowing them to continue their good work.

As a mere physician, I cannot replace the unique, specialized jobs that these families do and the benefit they offer wider society (i.e., I may not even be capable of forking and maintaining a project to the same degree of competence). If some great family is lost due to advanced age or suicide (i.e., they abandon their project), I might be able to memorialize and promote the work they have done (i.e., publish a fork which fixes a certain bug), but I cannot replace the work they do.

Even if I do try to carry on the vital work of some sick family, it comes at a cost to me to have to promote the work of others (i.e., making a fork) when I could instead be focusing on my job as a physician and they could be be restored to health, doing their own work, sometimes in a more skilled manner than I could, and hopefully chastened enough to take better care of themselves in the future for the benefit of all.

your rigor should be limited by the rigor all project developers enjoy.

This is to me like saying that a physician should not get the highest training or give the best care but should rather not seek to excel any other student in his class or provide better treatment than the local clinic. Why can't we have a mutually-concerned society, where we encourage the highest public standards for all, yet all the while allowing individuals who wish to do so to promote the adoption of good practices through demonstrating by the power of example in doing their job well that health checks do work. We don't need to let a whole segment of society sink just because it makes decisions against their own better interests in some area.

Thanks for your engagement on this topic!

[kaicataldo]

To chime in from the perspective of a maintainer, the case you outline is not one I've encountered nor one I would recommend. I think it's fine for you to want to use ESLint to improve someone else's codebase, but it feels out of the scope for the project to support running multiple times over the same files with different (read: potentially conflicting) configurations.

My recommendation would be to create a tool that wraps ESLint and to use that, if this is something you want to pursue.

[brettz9]

Thanks @kaicataldo . I do understand such configs could be a bit of a footgun where one really does need caution to avoid potentially conflicting configurations (thankfully there is overrides to help meet specific project needs), including harder to detect cases where one's personal config might wrongly suppress an error (rather than where one's personal config is just being more rigorous). But when carefully chosen, e.g., to only add rules which indicate problems, and to choose the rigorous settings, I am finding this can be extremely helpful.

I'd of course also understand any exception here if it becomes a technical burden for you to maintain, though if necessary, I'd hope that if core changes become necessary to practically support external tools to do such mixing (at this point, I'm not sure any changes are even needed--see below), that you may evince a similar kind of tolerance and accommodatability as I thought was communicated in eslint/eslint#8348 (toward allowing eslint to run in the browser--offering to make small, reasonable changes if needed).

Also, just to be sure...Does the deprecation of personal configs mean that there will be any change to configs stored in the home directory, i.e., if one wishes to use a home config to override other projects nested within home, I assume eslint will not be going against its normal algorithm and preventing this ability just because a config is present in HOME?

[brettz9]

There is one small core addition which I think would be helpful, and that is a command line flag to disable root: true from preventing further inheritance. By requiring opt-in, I would think this shouldn't be a very controversial addition and would accommodate those of us trying to lint such projects in this manner.

[ljharb]

Nothing should alter root true.

[brettz9]

Because the creator of the project with root:true overrides the desire of its consumers??

[brettz9]

If there is concern about it having unintended consequences (e.g., since a project might itself have multiple nested configs, thus causing the lack of root:true to be problematic even for the home config), it could be named, --unsafe-disable-root-check (and one would need to use --config for the rarer cases when root:true is both present and hierarchical within a project).

[ljharb]

Yes, the creator of the project has the ultimate authority in how to lint that project. The contributors have to obey what the maintainers want.

Git repos are a development environment, their consumers are the developers who aren’t in charge.

[brettz9]

The creator of the project has the ultimate authority in how to publish their project (or run their private CI routines which may check the linting standards they wish). People cloning their repository can lint it with whatever tools they wish, and offer contributions inspired by such linting. I thought ESLint was about giving people choices, and to date, in my experience, it has been. I'm encouraged though by the words of @kaicataldo :

...I think it's fine for you to want to use ESLint to improve someone else's codebase

I'd like to hear from the maintainers about whether they can make this small accommodation to faciltiate such use cases.

[ljharb]

If they want to lint it with whatever tools they wish, they need to modify the config files. Just cloning a project, without modifying it, doesn't mean you own it - it still belongs to its maintainers. If you want to own it (and thus decide how it's linted), you should have to modify it.

[brettz9]

Consumers don't need to modify the config files in many cases even as it is now--they can use --config and --no-eslintrc. But to get the benefit of both the project's preferences, as well as whatever stricter linting they may not have included, one needs multiple configs. (While I believe one could explicitly import the project's config, this does not allow easy reuse across all of one's projects. I could perhaps create a script to make this dynamic, but then I will need special arguments each time I use it, may have difficulties getting my IDE linter to use these arguments, etc.)

"If you want to own it...you should have to modify [the config]"

I don't want to "own" their repo. That is the point. If I felt competent enough or had enough time, I could always make my own fork for every open-licensed project I used (which is the majority of what I work with) and added whatever linting I wanted. But that would be a colossal waste of time.

However, I do want to ensure that the projects I use are not overlooking best practices--including those cases when projects are too stubborn to recognize their own good in some areas, and if my stricter linting can find a bug, and the project owner accepts the change--even in cases where they are not open to changing the linting--then it will have benefited myself and my projects' consumers. In that sense then, I will "own" the resulting improvements, including subsequent improvements they make, yet I will not need to override their wishes on their project's internal config.

[ljharb]

How often do you find yourself working on a project that a) doesn’t have linting, b) your linting rules catch a bug, and c) the maintainers are unwilling to accept a linting rule that caught a bug? I’d be very interested to understand that scenario.

[brettz9]

That is a very fair question (though I should mention that sometimes it is not that the project doesn't have any linting at all, but may only be using "eslint:recommended" but not say the goodness of eslint-plugin-unicorn, eslint-plugin-no-unsanitized, etc.). Indeed after finding a bug, one can often convince others to add the rule in question.

However:

1. I have encountered a couple project owners who are against expansive linting, not because of laziness, but apparently because they are minimalist and think it is more intimidating in deterring would-be developers to have too many devDependencies. One developer only wanted standard the CLI, but not any other added devDeps. (They may not have been against a similar CLI which was more rigorous, but then one would have to find or build one that met the needs in question, as standard does not catch all cases either.)

2. For another popular project I work with, the developer was open to rules catching a bug but asked me to propose adding specific rules one-by-one to his config. But this would require added effort on my part, beyond just say adding a new devDependency and a single line in .eslintrc.js as I would prefer. He wanted me to submit issues and PRs to his own config project so it would have those rules (I'd be fine mentioning the rules I was using if he would add them himself, but I don't want to spend my time to help everyone build up their own published configs when they could just extend an existing config or if they were unwilling, where I could instead use an albeit imperfect solution of checking against my personal config and choose to prioritize my time what I saw as more productively).

3. Even more to my concern, and of even more frequent occurrence, are developers who don't want linting at first, as they may be unconvinced they have any bugs, but in order to prove them wrong (if they were wrong), I'd need to go through the trouble for each such project of adding my config to their local config, installing local devDeps, seeing if there were bugs, and then reporting any I find. However, if I don't happen to find any bugs, then I may have wasted time, as I may find that, without evidence of a discovered bug, the project owner might not even want to accept my config changes to prevent future bugs (and it may not be a project I can just fork). I encounter quite a few developers--some of whom perhaps haven't worked on a particular project for a long time but happened to have done some good work a while back (and perhaps may resume in the future if they again have the need)--but who can't be bothered to add preventative tooling when there is no immediate problem shown to them (and which I can't detect are present until I go through added hoops of installing to their project--no less complicated by the fact I am forced to use a slow connection where I am).

So it is a bit of a chicken-and-egg problem. Without a means of applying my own rules, I can't freely and quickly take a look at any new project I want to kick the tires on, and have to spend my limited time adding config which may never get incorporated. If I have a means of applying my own rules, however, then I can easily identify specific bugs and the rules which catch those bugs, and appeal to the owner to add them.

4. One developer of a very prominent project even rather surprised me when I provided a tentative PR showing likely bugs yet this person was not interested in using it as a base to fix the bugs, because it would have required some investigation to make sure they were problematic. (I was just offering it as a courtesy as I use the project and happened to have a linting tool reporting on this. But when I mentioned in this particular case that I wasn't 100% sure the fixes were appropriate, I still would have expected that likely problems would at least be of interest.)

For example, when a meaningless regex escape like \a was found, was it because it should have been searching for \\ and then a or was it only searching for a--or did the develeper intend some other escape sequence? Or more seriously, I recall there was a \s in a string-based regex which I'd bet was intended as a whitespace check, but was being treated as just an "s" check so almost certainly not working as intended. At the very least, these were bad and confusing practices. Yet this very useful project wasn't interested in being alerted to the likelihood of specific problems, how much more no doubt if I tried to add a different linting process.

[ljharb]

My perspective is that if it's not worth you spending the time on improving these projects (which, obviously, you shouldn't have to be doing!), then why do you want to use these projects, instead of switching to one of a dozen other properly linted alternatives?

[brettz9]

I should clarify only the last case was one for which I felt I did not have any real time to improve the project despite having honed in on likely problems. And for that project, the project in question is miles ahead of the other alternatives in terms of performance and is used extremely widely. I normally would have had time to fix it, but it just so happened that delving into that code base, as much as I use it, isn't currently as much of a priority for me as other priorities.

For the unnecessary time-wasting I felt that is part of the other types, if I had unlimited time, I wouldn't mind doing the work of improving them. And despite what I perceive to be their inefficiencies, I can and do often spend time on improving such projects precisely because I found them to be the best projects, having investigated any alternatives.

There are some fortunate cases where the, often big, well managed projects of the Node ecosystem are well-linted, respond quickly to issues, etc., but there are also so many packages which written by the genius type who starts a project that is far better than any others and doesn't give it much loving (though a good number will still accept fixes)--even in some cases with a huge chunk of the Node ecosystem depending on such projects (another reason I may not have time to switch--because it is used by various other dependencies).

As much as I, as a fan of the added sanity brought by linting, may sometimes be tempted to conclude that openness to linting correlates entirely with project robustness, the fact is there are also a lot of messy and productive geniuses out there (and no doubt some properly linted projects of little comparative use).

[multics]

My use case is: when I try things, I do not create eslint config, but I still hope experimental code could be checked against my group of 'personal rules' as a default set of eslint rules. If I decide to create a project, I will definitely create a eslint config so all the project team members could use the same rules. This approach saves me lots of time to config eslint because I almost always use the same config for my new things. It is worth to saving time, right??

Yes. I saw the plan, --config option. Is this plan good enough to replace the legacy feature? Since I've configured my vscode to use the personal config when it could not find a eslint config in working directory. Ok, I know we can ask vscode eslint extension providers to add an option/functionality/feature to do so. But why?

[multics]

Eslint itself as a good global tool is very smart.

WHY ESLINT HAS TO BE BOUND TO A PROJECT?

[ljharb]

What experimental code are you writing that has no dependencies?

[multics]

Does it matter? The point is eslint as a global tool with a global config saves time.

[aladdin-add]

I can see a value of global usage, the problem is: the feature was not well-designed, and caused a lot of confusion. Hopefully we can reintroduce the global usage in a future version someday.

[multics]

That would be nice! ❤️

As I read this thread, I've got to know globally installed eslint is not encouraged , and the team will deprecate this kind of usage in v8.0.0. You know, to me eslint is a wonderful tool, it is so good, and should not be limited to just project level usage.

Please do consider to continue supporting global usage. ❤️

I know it is hard, and I too, do not like the idea that installing all dependencies in home dir, and I use nvm/npm and I have googled and finally figured out how to avoid installing all the packages in home dir. Here is the original post .

It's ugly, but it works as I expected: install all stuff in global instead of home dir.

This is my personal config, FYI.

'use strict'

const global_path = `${process.env.HOME}/.nvm/versions/node/v14.0.0`
const Module = require('module')

const hacks = [
  'eslint-config-personal',
  'eslint-plugin-html',
  'eslint-plugin-svelte3',
  'svelte',
]

const ModuleFindPath = Module._findPath
Module._findPath = (request, paths, isMain) => {
  const foundOne = ModuleFindPath(request, paths, isMain)
  if (!foundOne && hacks.includes(request)) {
    return require.resolve(`${global_path}/lib/node_modules/${request}`)
  }
  return foundOne
}

const config = {
  root: true,
  env: {
    browser: true,
    node: true,
    es6: true,
  },
  extends: [
   'eslint-config-personal',
  ],
  plugins: [
    'html',
    'svelte3',
  ],
  rules: {
    'no-sync': 'off',
    'no-console': 'off',
    'no-new': 'off',
    'no-empty': 'off',
    'no-restricted-modules': 'off',
    'comma-dangle': ['warn', 'always-multiline'],
    'prefer-const': ['warn'],
  },
  parserOptions: {
    sourceType: 'module',
    ecmaVersion: '2019',
  },
  overrides: [
    {
      files: ['*.svelte'],
      processor: 'svelte3/svelte3',
    },
  ],
}

module.exports = config

Thanks for your patience!😀

[ljharb]

Yes, it matters, because it saves time in the short term at the cost of wasting time in the long term, when your experimental code doesn’t have any eslint version or config attached and suddenly needs to be a project, shared among multiple devs. Short term convenience is rarely a good tradeoff for long term costs.

[multics]

It would be my job to balance short term and long term cost, isn't it right?

And again, my point is eslint working as a global tool matters.