Path case sensitivity issue causing require/import related plugin false errors

[jaydenseric]

Issue Type

Bug.

Issue Description

For both eslint-plugin-node/no-missing-require, and eslint-plugin-import/no-unresolved linter-eslint is throwing up false errors, while the CLI doesn't.

A clue is that the import/unresolved error mentions that the casing doesn't match the underlying filesystem. By disabling case sensitivity, the error goes away.

I suspect that incorrect casing of a path is causing the other plugin too error also, as it is also case sensitive. Unfortunately, it doesn't have an option to disable the case sensitivity.

Debug in file with import/no-unresolved false errors:

Atom version: 1.17.2
linter-eslint version: 8.2.1
ESLint version: 3.19.0
Hours since last Atom restart: 0.2
Platform: darwin
Using local project ESLint from: /Users/jaydenseric/Sites/Grapple/app/node_modules/eslint
Current file's scopes: [
  "source.js.jsx",
  "meta.delimiter.comma.js"
]
linter-eslint configuration: {
  "fixOnSave": true,
  "lintHtmlFiles": false,
  "useGlobalEslint": false,
  "showRuleIdInMessage": true,
  "disableWhenNoEslintConfig": true,
  "eslintrcPath": "",
  "globalNodePath": "",
  "advancedLocalNodeModules": "",
  "eslintRulesDir": "",
  "disableEslintIgnore": false,
  "disableFSCache": false,
  "scopes": [
    "source.js",
    "source.jsx",
    "source.js.jsx",
    "source.babel",
    "source.js-semantic"
  ],
  "rulesToSilenceWhileTyping": [],
  "rulesToDisableWhileFixing": []
}

Debug in file with node/no-missing-require false errors:

Atom version: 1.17.2
linter-eslint version: 8.2.1
ESLint version: 3.19.0
Hours since last Atom restart: 0.3
Platform: darwin
Using local project ESLint from: /Users/jaydenseric/Sites/Grapple/app/node_modules/eslint
Current file's scopes: [
  "source.js.jsx",
  "meta.function-call.with-arguments.js",
  "meta.brace.round.js"
]
linter-eslint configuration: {
  "fixOnSave": true,
  "lintHtmlFiles": false,
  "useGlobalEslint": false,
  "showRuleIdInMessage": true,
  "disableWhenNoEslintConfig": true,
  "eslintrcPath": "",
  "globalNodePath": "",
  "advancedLocalNodeModules": "",
  "eslintRulesDir": "",
  "disableEslintIgnore": false,
  "disableFSCache": false,
  "scopes": [
    "source.js",
    "source.jsx",
    "source.js.jsx",
    "source.babel",
    "source.js-semantic"
  ],
  "rulesToSilenceWhileTyping": [],
  "rulesToDisableWhileFixing": []
}

[controversial]

In addition to a false import/no-unresolved error when using linter-eslint, I'm also seeing "Resolve error" messages for each eslint-plugin-import rule in every file that uses imports:

I don't see these from the CLI, only in Atom. I'm on macOS Sierra.

[IanVS]

Thanks for the reports. Is anyone able to provide a small example repo or zip file which demonstrates the issue? That would be a big help in troubleshooting.

[controversial]

@IanVS I tried to put together a reproducible case in https://github.com/controversial/linter-eslint-934-repro, but it doesn't display the error. I do have a very large repo that shows the issue, however, here's a zip: link removed by @Arcanemagus

Check out app/src/main.js in that, for example.

[IanVS]

Thanks @controversial, that's helpful. I found that removing

    "settings": {
      "import/resolver": "webpack"
    },

from your package.json resolved the errors. I'm not sure why that would be, but I did a little investigation, and the error starts to occur with our move to the task api. @Arcanemagus, can you think of any reasons that particular commit might cause the webpack resolver to break? I verified that cwd is still correctly being set to the root directory, so it's not that.

[Arcanemagus]

So this is actually all your fault @controversial 😛.

The tl;dr is that you are assuming a CLI environment in your webpack.config.js on line 95 with this line:

const isDevServer = process.argv[1].indexOf('webpack-dev-server') !== -1;

If you change it to something like this, things work perfectly:

const isDevServer = process.argv[1] ? process.argv[1].indexOf('webpack-dev-server') !== -1 : false;

As for why this showed up when we moved to the Task API, this was actually introduced way back in #873, but since we were still using a custom wrapper around the worker thread, process.argv[1] must have still existed. The Task API cleans all that up considerably... but means that it no longer had arguments to check against so the config then failed.

Normally errors like this would be forwarded on from the worker and shown in Atom's console, but it seems that eslint-plugin-import "eats" the errors and doesn't re-throw them up all the way to where we can grab them in the worker, leading to the ever so helpful error message you were getting.

Let us know if you run into any further problems and thanks for reporting this!

Note: Removed the link to your full repro case as it looks to be a private repo.

[controversial]

Ok, thanks a lot!

…

On Wed, Jun 14, 2017 at 2:56 PM Landon Abney ***@***.***> wrote: So this is actually all your fault @controversial <https://github.com/controversial> 😛. The tl;dr is that you are assuming a CLI environment in your webpack.config.js on line 95 with this line: const isDevServer = process.argv[1].indexOf('webpack-dev-server') !== -1; If you change it to something like this, things work perfectly: const isDevServer = process.argv[1] ? process.argv[1].indexOf('webpack-dev-server') !== -1 : false; As for why this showed up when we moved to the Task API, this was actually introduced way back in #873 <#873>, but since we were still using a custom wrapper around the worker thread, process.argv[1] must have still existed. The Task API cleans all that up considerably... but means that it no longer had arguments to check against so the config then failed. Normally errors like this would be forwarded on from the worker and shown in Atom's console, but it seems that eslint-plugin-import "eats" the errors and doesn't re-throw them up all the way to where we can grab them in the worker, leading to the ever so helpful error message you were getting. Let us know if you run into any further problems and thanks for reporting this! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#934 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ5YrzHuWe3errYQeI9X_c5DfIjKHpSeks5sECzKgaJpZM4NvnlZ> .

[Arcanemagus]

Whoops, @jaydenseric your issue is different from the one discussed above with @controversial. We need some method of reproducing your error in order to diagnose it.

[xxsnakerxx]

Same issue on MacOS Sierra

I found workaround... change this line to this

const CASE_SENSITIVE_FS = fs.existsSync(path.join(__dirname, 'reSOLVE.js'))

[Arcanemagus]

@xxsnakerxx That would make case in-sensitive filesystems show up as case sensitive, breaking the functionality of eslint-plugin-import.

[andreidobrinski]

Experiencing a similar issue today. If it helps, I see the no-unresolved issue when opening the project by navigating to it in the terminal and running atom .. The linter reads "Casing of [import] does not match the underlying filesystem."

Otherwise, when I open the project through Atom's browser, the issue does not exist.

FWIW, I'm also seeing duplicates of the projects that I opened with atom . in the File > Reopen Project dropdown.

[Arcanemagus]

@andreidobrinski Please file a new issue with an example repository / .zip archive to reproduce it, but from the sounds of it you have some sort of OS level issue that is beyond the scope of this package.

Closing this as @jaydenseric hasn't responded past the initial report.