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

Problems if resolved path is absolute #310

Closed
lukeapage opened this issue May 6, 2016 · 5 comments
Closed

Problems if resolved path is absolute #310

lukeapage opened this issue May 6, 2016 · 5 comments

Comments

@lukeapage
Copy link
Contributor

Hi,

I'm trying to get the plugin working on a large complicated setup. I'm on windows, using the webpack resolver. When modulesDirectories is set and used to resolve, the "resolve" module can return absolute paths - if this is returned from the resolver then 'no-unresolved' fails.

I have a simple fix in the webpack resolver to do this

    if (path.isAbsolute(resolvedPath)) {
        resolvedPath = path.relative('.', resolvedPath);
   }

Do you want a PR for this or do I need to investigate why absolute paths fail in the main plugin?

@lukeapage
Copy link
Contributor Author

hrmm ok.. so its failing because the path case doesn't match.. but the path with the wrong casing appears to be coming from the resolve module...

@lukeapage
Copy link
Contributor Author

lukeapage commented May 6, 2016

the resolve module calls path.dirname(caller()) and gets back a path for instance c:\Test\test\Test but the filesystem actually has c:\Test\Test\Test
so maybe its a minor node bug. I will try upgrading my node. (I'm on 4.2.3)

@lukeapage
Copy link
Contributor Author

In Node v6 its fixed.
In Node v4.4.4 its not.
The root cause is I had typed cd /Test/test and bash had set the path with the lowercase version. Because thats the path that eslint was running from..

It might be useful to have an option to disable the case sensitive check, it seems like there is plenty of scope for mistakes...

@benmosher
Copy link
Member

I think I'll make a note in the README, at the very least. You're not the first person to run into this on Windows; apparently running from PowerShell exhibits the same behavior.

I think it might be fairly simple to ignore case issues for the CWD and only validate deeper paths.

@lukeapage
Copy link
Contributor Author

It might be useful in general to be able to disable case checking - I'm a bit scared of what will happen once I fix the 60 other case violations and run it on the build machine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants