-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
Can you elaborate? |
There. Sorry for the closing and opening. |
Interesting. I think as well that perhaps on case-insensitive file systems, that should be detected, so that all paths are lowercased for consistency. |
Perhaps, but the test is correct for local projects I think. If you have a 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. |
That makes sense - that as a best practice, you want casing to match exactly, but only within the project root. |
Yes, precisely. |
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 |
For me, i've following import.
it still gives error while running eslint from command line.
is it a false positive? |
Simply prevent eslint to check any parent folder of current working directory.
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. |
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 |
merged, will go out in v2.8.0 😅 |
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.
I was getting a lot of false positives like this:
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:When using your lint rule
import/no-unresolved
, this will crash with the above false positives. They will disappear of you go into the directoryGit
instead ofgit
.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...The text was updated successfully, but these errors were encountered: