-
Notifications
You must be signed in to change notification settings - Fork 140
Path case sensitivity issue causing require/import related plugin false errors #934
Comments
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. |
@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: Check out |
Thanks @controversial, that's helpful. I found that removing
from your |
So this is actually all your fault @controversial 😛. The tl;dr is that you are assuming a CLI environment in your 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, Normally errors like this would be forwarded on from the worker and shown in Atom's console, but it seems that 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. |
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>
.
|
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. |
Same issue on MacOS Sierra I found workaround... change this line to this const CASE_SENSITIVE_FS = fs.existsSync(path.join(__dirname, 'reSOLVE.js')) |
@xxsnakerxx That would make case in-sensitive filesystems show up as case sensitive, breaking the functionality of |
Experiencing a similar issue today. If it helps, I see the 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 |
@andreidobrinski Please file a new issue with an example repository / Closing this as @jaydenseric hasn't responded past the initial report. |
Issue Type
Bug.
Issue Description
For both
eslint-plugin-node/no-missing-require
, andeslint-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:Debug in file with
node/no-missing-require
false errors:The text was updated successfully, but these errors were encountered: