Change for relative path algorithm

[brettz9]

Issue Type

Issue Description

I have some ESLint in my HOME, with its own .eslintignore, node_modules (including eslint copy), etc.

In one project, I did not have an .eslintignore. This caused getRelativePath of src/worker-helpers.js to look up in a higher directory (here, HOME) and finding an ignore file there, set that as the cwd (e.g., for eslint).

The ignore files are not what eslint itself looks at for determining hierarchy, though I understand per a note in source that you use the position of the ignore file (rather than using a config file which may be present at different paths within the project hierarchy) as the project root:

// If we can find an .eslintignore file, we can set cwd there
// (because they are expected to be at the project root)

However, perhaps the result of findCached could be checked to make sure it is not at a higher directory than the project path.

The following change seems to have fixed it:

Changing the following line from getRelativePath:

if (ignoreFile) {

...to:

if (ignoreFile &&
  // The ignore file could be higher than the Atom projectPath if the Atom project has no ignore but the containing folder (e.g., HOME) does:
  (!projectPath || Path.dirname(projectPath).includes(ignoreFile))) {

Bug Checklist

• Restart Atom
• Verify the eslint CLI gives the proper result, while linter-eslint does not
• Paste the output of the Linter Eslint: Debug command from the Command Palette below

(I got the following message, as my HOME eslint plugin copy was outdated, but I wasn't expecting it to use the HOME config since I didn't specify that as my config)

Linter Eslint: Definition for rule 'unicorn/better-regex' was not found. (unicorn/better-regex)

[Arcanemagus]

How are you running eslint normally that works where this doesn't? It sounds like you are deep in edge cases for this to work at all. 😕

[brettz9]

Hehe... Well, though personal configs are deprecated, the ability to have linting in HOME is thankfully not (I have my repos within HOME).

I like to take a config I have in HOME (normally named .eslintrc-main.js) and temporarily rename it to .eslintrc.jsso that I can see the combined effect of my config against a project's own config in Atom (which I can do in this way so long as that project does not use root: true).

I don't do this normally since there can be subtle conflicts in allowing projects to be combined with one's own rules, and in the course of normal work, the project's linting has priority anyways. However, adding my own personal config to the mix can be useful toward enforcing stricter standards than a project might be willing to adopt (though where the project is not against fixes inspired by such rules), especially when either confining oneself to few HOME rules or adding project-specific overrides to one's HOME config to allow the project to take precedence where deliberately laxer (e.g., they don't want to be bothered to restyle some things) yet not unsafe.

I therefore have node_modules in HOME with eslint and copies of eslint plugins used across my repos (regardless of how linter-eslint does it, this also lets me lint at HOME, e.g., for auditing a subproject or subprojects--see below).

As far as the ignore file in HOME, I use that so that I can add back files which a project does not lint by the ! unignore (e.g., !*.js to reenable hidden JS file linting), along with ignoring my Desktop, etc. which I do not wish searched for repos. I can also add project-specific paths here to ignore if needed (e.g., for projects which rely on standard, which only whitelist files to lint, or otherwise eschew an ignore file).

While I am aware that I could point to a non-HOME RC file elsewhere with --config (and a specific ignore file with --ignore-path):

1. That causes the referenced HOME config to be of higher priority per https://eslint.org/docs/user-guide/configuring#configuration-cascading-and-hierarchy .

2. I'm not clear that linter-eslint supports this through its options anyways (I do see you have an option to specify an eslintrc path but:

   1. As it is listed under "Global ESLint", I'm not clear whether that only works when using a global ESLint installation.

   2. I don't want to set this usually and mistakenly think that projects have linting when they do not. It is easier for me to remember to rename a file on my desktop than have to look through config.)

(Note that since a project can override the HOME (or use root: true), this inheritance approach does not work for auditing projects; for that, one can use --config with --no-inline-config and --no-eslintrc and point to the config/ignore files of interest, whether in HOME or elsewhere).

So in summary, though it can require some work to set things up, I don't think it is too obscure to want to be able to check other projects in a stricter manner than the project's current config allows, especially if one is not motivated to make one's own fork. The fix I provided too shouldn't be too obtrusive either I would think.

Thanks!

[scesbron]

This problem of relative paths is also present for monorepos.

Maybe getRelativePath can look for the presence of .eslintrc.json instead of .eslintignore to determine the path to execute eslint from.

This is what webstorm just did recently

IDE looks for the directory closest to the linted file which contains the .eslintrc.* file (or package.json file with either "eslintIgnore" or "eslintConfig" property)