New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Personal config (~/.eslintrc) doesn't load global-installed configs/parsers/plugins #11914
Personal config (~/.eslintrc) doesn't load global-installed configs/parsers/plugins #11914
Comments
Thank you for your report. How do you run |
Hi @mysticatea, thanks for you help. It seems you gotta reason because, as I read, "With ESLint v6, plugins should always be installed locally, even if ESLint was installed globally". |
I'm a VSCode user, too. If you installed If you want to use global installation, use In VSCode case, configure |
It seems not working, also via CLI.
The error persists also if I downgrade to version 6.0.0, but I'm sure that npm prefix is correct and the path of the file is correct too. |
Would you provide the result of eslint command with |
Oh sure, here the output:
Moreover if I run I got this output:
It let me think that all gone well but I always receive the error I said before. |
Thank you! Hmm. Looks like that it failed to load Would you check what |
I got this error:
The error is the same if i type |
OK, thank you very much. I think I found what's happened.
This means that If you installed that shareable config into your home directory, I guess it works. |
So there's no other way than install the package where the config file is? Mmmm.... so bad.... I think I rollback to eslint 5. Any way thanks for your support :-) |
I understand your position. I agree that the current personal config's behavior is not convenient. @eslint/eslint-team ESLint uses (for a reference, lib/cli-engine/cascading-config-array-factory.js#L372-L384 is the code to load the personal config. I'm imaging to add a flag to that place to find also global-installed packages.) |
I don’t think it’s a good idea to install and run ESLint globally and I’m a little bit hesitant about adding more options, because it encourages using this behavior. Upgrading ESLint (even a semver-minor upgrade) can lead to more linting errors, and if someone had multiple projects on their machine they would potentially have to fix up errors in every project each time they upgrade. If this same person collaborates with others (or runs automated testing), not defining the version in package.json can lead to mismatching results between runs. That being said, I recognize that we already support this feature and I do think this change makes sense, given that we currently are supporting global installations. |
I'm getting the same problem. will roll back eslint |
Hi, I have a similar use-case, that worked well until 6.x We have a mono-repo, no lerna or fancy tools.
All peerDependencies of that config are specified and installed per packages. I think that was a simple and effective pattern. Will this definitely be impossible now? |
No, it doesn't make migration difficult. It makes it impossible for many of us. I know I can pass loader options. But again, it would require manual config from every user for every project then, which is unacceptable. Imo ESLint should be able to resolve these things relative to the Anyway, I'm starting to feel like I'll need to patch manually ESLint on file-system level to make this work. I really want to avoid this... There would be so many solutions to resolve this issue:
I'm sure this thread will keep growing with reports from other users when they start to update their codebase. |
As another option, you could create a wrapper script around ESLint that always invokes it with a specific set of options, to prevent users from always needing to supply additional CLI options. As for your other suggestions: We're always open to looking at RFCs for behavior changes. It might be worth noting that several of the suggestions have been discussed in detail on other RFCs (e.g. here and here). Speaking more broadly, I'm not sure it's realistic to expect that a tool's default settings will know how to handle every unusual custom setup. We try to provide reasonable default behaviors that work for the vast majority of users, and also allow for a great deal of customization (e.g. with CLI flags) that allows people to make things work with their own setup. But in order for that to work, one has to be willing to actually use the customization options. |
A short question: If we have |
my 2cents: I can't upgrade eslint past v5, as ALE in Vim will report 'Failed to load config "standard"' - just as CLI does. I've read all issues here related to forcing users to stop using a global config, and I don't agree for reasons already cited above in this ticket. I see no option open to me atm than to slowly die on v5? That does not seem reasonable |
I had enough of this and created the following package: It is a very unsafe and ugly workaround, it'll patch your ESLint installation. For my use case it works fine for all our projects. |
I believe that 5.x issues "design bug" affected less installations that 6.x design broke now. Standalone ESLint (outside node project) is now quite unusable. I have to change my editor --resolve-plugins-relative-to based on that if local project use node.js. IMHO best solutions should be:
|
What it needs is that is working as any other module in the NodeJS ecosystem. ESLint cannot resolve modules relative to itself currently! |
I updated to eslint 6.7.2 but still I'm unable to use global modules. When i run
{
"env": {
"browser": true,
"commonjs": true,
"es6": true,
"node": true
},
"extends": [
"standard"
],
"parser": "babel-eslint",
"parserOptions": {
"ecmaFeatures": {
"jsx": true
},
"sourceType": "module"
},
"plugins": [
"html",
"css-in-js",
"json"
],
"rules": {
"no-const-assign": "warn",
"no-prototype-builtins": "off",
"no-this-before-super": "warn",
"no-undef": "warn",
"no-unreachable": "warn",
"no-unused-vars": "warn",
"constructor-super": "warn",
"valid-typeof": "warn"
}
} What am I wronging now? |
My solution: // ~/.eslintrc.js
'use strict';
const Module = require('module');
const hacks = [
'eslint-config-airbnb-base',
'babel-eslint',
];
const ModuleFindPath = Module._findPath;
Module._findPath = (request, paths, isMain) => {
const r = ModuleFindPath(request, paths, isMain);
if (!r && hacks.includes(request)) {
return require.resolve(`${process.env.HOME}/.npm-global/lib/node_modules/${request}`);
}
return r;
};
module.exports = {
extends: 'airbnb-base',
parser: 'babel-eslint',
... etc
}; this is so incredibly stupid. please add back global resolution in some capacity. |
Tell us about your environment
What parser (default, Babel-ESLint, etc.) are you using? default
Please show your full configuration:
Configuration
What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.
I updated eslint from version 5.16.0 to 6.0.1 and, since I did it, eslint failes to start and I always receive this error: 'Failed to load config "standard" to extend from eslint 6'.
What did you expect to happen?
I expected that all worked fine.
The text was updated successfully, but these errors were encountered: