Eslint-plugin-import: False positives in import/no-unresolved when command is run from path not correctly cased

[hnilsen]

I was getting a lot of false positives like this:

   1:34  error  Casing of react does not match the underlying filesystem                                            import/no-unresolved
   2:25  error  Casing of react-redux does not match the underlying filesystem                                      import/no-unresolved
   3:27  error  Casing of redux-form does not match the underlying filesystem                                       import/no-unresolved

In Windows, you have a case-insensitive file system which enables you to enter directories regardless of their casing. I.e. the path: C:\Git\projects\myproject\src can be entered like this:

cd C:\
cd git <-- this is the culprit
cd projects
cd myproject
cd src
npm run eslint

When using your lint rule import/no-unresolved, this will crash with the above false positives. They will disappear of you go into the directory Git instead of git.

I think the lint rule should not go further back than the level where the package.json is. This problem will appear when you're using either PowerShell or Bash. And it was a huge pain to figure out...

[ljharb]

Can you elaborate?

[hnilsen]

There. Sorry for the closing and opening.

[ljharb]

Interesting. I think as well that perhaps on case-insensitive file systems, that should be detected, so that all paths are lowercased for consistency.

[hnilsen]

Perhaps, but the test is correct for local projects I think. If you have a util function, for instance, and you import it like this: import util from 'Util/Util', it should yield and error if the proper casing is util/util.

The problem here is that the check recursively goes down the path all the way down to root to check the casing, and it shouldn't do that imho.

[ljharb]

That makes sense - that as a best practice, you want casing to match exactly, but only within the project root.

[hnilsen]

Yes, precisely.

[bradchristensen]

Woah! I had no idea that this was the reason I was seeing this on some of my co-developers' machines but not others. :stuck_out_tongue:

Affects the linter-eslint plugin in Atom too, e.g. if you open Atom from a PowerShell by cding to your directory (using incorrect casing) and then running atom .

[hvelani]

For me, i've following import.

import * as _ from 'lodash';

it still gives error while running eslint from command line.

error Unable to resolve path to module 'lodash' import/no-unresolved

is it a false positive?

[sag1v]

hmmmz i still got it (on a component a teammate created) but it is not stable, sometimes i get this warning and sometimes not. seems like i don't have any mistakes in the path.
I'm using vscode and windows 8.1 (my team mate uses win7)

[sage911]

Wow, nice find! I've been trying to figure out wth is going on for the past hour and a half. I get the error in Atom when I launch from terminal using incorrect casing somewhere along the way

[benmosher]

merged, will go out in v2.8.0 😅