Skip to content
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

False positives in import/no-unresolved when command is run from path not correctly cased #720

Closed
hnilsen opened this issue Jan 13, 2017 · 11 comments

Comments

@hnilsen
Copy link

hnilsen commented Jan 13, 2017

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...

@hnilsen hnilsen closed this as completed Jan 13, 2017
@ljharb
Copy link
Member

ljharb commented Jan 13, 2017

Can you elaborate?

@hnilsen hnilsen reopened this Jan 13, 2017
@hnilsen
Copy link
Author

hnilsen commented Jan 13, 2017

There. Sorry for the closing and opening.

@ljharb
Copy link
Member

ljharb commented Jan 13, 2017

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

@ljharb ljharb added the bug label Jan 13, 2017
@hnilsen
Copy link
Author

hnilsen commented Jan 13, 2017

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
Copy link
Member

ljharb commented Jan 13, 2017

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

@hnilsen
Copy link
Author

hnilsen commented Jan 13, 2017

Yes, precisely.

@bradchristensen
Copy link

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

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
Copy link

hvelani commented Mar 14, 2017

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?

laysent added a commit to laysent/eslint-plugin-import that referenced this issue Jun 1, 2017
Simply prevent eslint to check any parent folder of current working
directory.
@laysent laysent mentioned this issue Jun 1, 2017
@sag1v
Copy link

sag1v commented Aug 3, 2017

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)

@saaage
Copy link

saaage commented Aug 9, 2017

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
Copy link
Member

merged, will go out in v2.8.0 😅

thai-truong referenced this issue in HKN-UCSD/old-hkn-server Jun 28, 2020
I've added most of the changes commented on the PR,
but I left out styles.js in SignUpPageNew since I can't
make things look nice without lots of hardcoded margins
and paddings for <Card />, as opposed to <Grid />.

Changes:
  - Got rid of !! and ?? operators in the dropdown files
  - Put schema in a separate file (schema.js)
  - Added index.js in dropdowns to export both major and
    year dropdowns with 1 import statement.
  - Put in proper changes for <Grid /> in SignUpForm so
    things look better now and I got rid of most of the
    hardcoded margins and paddings for styles.js.
  - Added clarification to what getIn() does as comments
    in the dropdown files.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

7 participants