Bug: (eslintignore breaks when cwd is using forward slash on windows)

[noe132]

Environment

Node version: 19.7.0
npm version: 9.5.0
Local ESLint version: 8.37.0
Global ESLint version: N/A
Operating System: windows 10 x64

What parser are you using?

Default (Espree)

What did you do?

When passing cwd option to eslint with a path with forward slash on windows (C:/path/to/project), eslintignore breaks and errors were reported from ignored files.

folder structure:

src/1.js
src/dist/2.js
.eslintignore
.eslintrc.js
lint.js

src/1.js

console.log(1)

src/dist/2.js

console.log(2)

.eslintignore

src/dist

lint.js

const eslint = require('eslint');

const run = async (cwd) => {
  // 1. Create an instance.
  const instance = new eslint.ESLint({ cwd, extensions: ['.js'] });

  // 2. Lint files.
  const results = await instance.lintFiles(["./src"]);

  // 3. Format the results.
  const formatter = await instance.loadFormatter("stylish");
  const resultText = formatter.format(results);

  // 4. Output it.
  console.log(resultText);
};

const main = async () => {
  await run(__dirname);
  console.log('-----------');
  await run(__dirname.replaceAll("\\", "/"));
};

main();

.eslintrc.js

module.exports = {
  parserOptions: {
    ecmaVersion: 2020,
  },
  'root': true,
  'rules': {
    'semi': 'error',
  },
};

result

C:\src\eslinttest\src\1.js
  1:15  error  Missing semicolon  semi

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

-----------

C:\src\eslinttest\src\1.js
  1:15  error  Missing semicolon  semi

C:\src\eslinttest\src\dist\2.js
  1:15  error  Missing semicolon  semi

✖ 2 problems (2 errors, 0 warnings)
  2 errors and 0 warnings potentially fixable with the `--fix` option.

What did you expect to happen?

eslintignore working as expected

What actually happened?

linting ignored files

Participation

• I am willing to submit a pull request for this issue.

Additional comments

Where I get this problem? Here.
I'm using vite-plugin-checker on my project. It pass a root param recieved from vite to eslint cwd option which happens to be a path with forward slash on windows.

[mdjermanovic]

Hi @noe132!

Thanks for the detailed description. I was able to reproduce this.

The problem seems to be that function getCommonAncestorPath expects given paths to have path.sep as the path separator, but gets the exact cwd that was passed into the ESLint constructor, in this case with forward slashes, and also gets a few more paths with backslashes from the system, and then doesn't work well with that mix.

I think the easiest solution would be to update the ESLint class to path.normalize() the cwd argument right away, and from that point on work with the normalized version only. @nzakas what do you think?

[nzakas]

That seems reasonable, though I'm curious if this is also an issue for FlatESLint?

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[nzakas]

@mdjermanovic following up here, do you think this is also an issue for FlatESLint?

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[Rec0iL99]

@mdjermanovic following up here, do you think this is also an issue for FlatESLint?

@mdjermanovic waiting for your response on this. Thanks.

[fasttime]

FlatESLint does not care about .eslintignore files, but it seems to me that the supported ways to ignore stuff with the flat config all behave well on Windows even when cwd contains forward slashes.

• with ignorePatterns: ['src/dist'] in the FlatESLint constructor options.
• with a global ignores pattern in the config: { ignores: ['src/dist'] }.
• with a non-global ignores pattern like ignores: ['src/dist/**'].
• with a negated files pattern like files: ['!src/dist/**'].

Maybe there is more to test, but so far I could not reproduce the issue described here with the flat config.

[mdjermanovic]

I didn't manage to find any observable problems either, but it might be good to do path.normalize() anyway so that rules can always expect context.cwd with local path separators.

[snitin315]

Marking this as accepted :)

[mdjermanovic]

I can work on this.