All imports unresolved when using PowerShell

[MrSauceman]

I could not figure out why all of my imports were showing as unresolved until I ran eslint in a normal command prompt rather than PowerShell. In PowerShell, all of my imports show up as unresolved, but when I run it at a normal command prompt, there are no errors.

In PowerShell, it doesn't resolve modules from node_modules directory, nor my local imports:

 error  Unable to resolve path to module 'react'         import/no-unresolved
 error  Unable to resolve path to module 'redux'         import/no-unresolved
 error  Unable to resolve path to module 'react-redux'   import/no-unresolved
 error  Unable to resolve path to module './../login'    import/no-unresolved

Has anyone experienced this, or know why this is happening? I assume it has to do with relative pathing and how PowerShell interprets them.

Edit: Forgot to say, when I hardcode the full path to a module that I am importing (c:\projects\src...), it works fine in PowerShell. It appears to be the relative paths and node_modules that do not work.

[benmosher]

Wild. I have no idea. I would guess something to do with the working directory (see recent Webpack resolver issues for some detail).

I am completely unfamiliar with PowerShell, though. Hopefully someone else has an idea. 😅

[MrSauceman]

I figured out the problem. It was a case sensitivity issue. I had cd'd into my project directory in Powershell without using the proper casing. For example, on disk the path was C:\Projects\src... and I had used cd c:\projects\src.... Powershell does not adjust the path to use the correct case as it appears on the disk, and instead moves you into the directory with the exact casing that you type. I think the code in resolve.js was checking that the entire path, not just the relative portion, had the proper case, and thus was failing to resolve.

The following condition in /src/code/resolve.js was true when running in powershell, causing all imports to show as unresolved.

if (filenames.indexOf(basename(filepath)) === -1) {
  result = false
} else {
  result = fileExistsWithCaseSync(dir, cacheSettings)
}

I dug a little deeper and checked the code for basename in the path module. It is as follows:

win32.basename = function(path, ext) {
  var f = win32SplitPath(path)[2];
  // TODO: make this comparison case-insensitive on windows?
  if (ext && f.substr(-1 * ext.length) === ext) {
    f = f.substr(0, f.length - ext.length);
  }
  return f;
};

I'm guessing that the TODO in there (as well as a quick glance at the code) means that the current version of that function is case sensitive, and is possibly contributing to this situation.

I'm not sure if this is an issue or not with the code in eslint-plugin-import or more of an issue with the path module. Feel free to close this if you take a look and decide it's not an issue with this plugin.

If you want to reproduce this issue, you can fire up powershell and cd into the project directory using incorrect casing and run the tests in this module - all of the resolve tests will fail.

If you need any more information, please let me know, I'm happy to help. Thanks!

[benmosher]

I think I will close this issue for now, seems like something that would be solved by making case-sensitive resolution optional.