no-unused-modules appveyor tests failing

[ljharb]

cc @rfermann

There's some appveyor tests failing due to #1142: https://ci.appveyor.com/project/benmosher/eslint-plugin-import/builds/23488849

What's particularly confusing is that a) they pass on travis and locally; b) one of the test cases is listed, identically, as both valid and invalid, so it shouldn't pass at all; there shouldn't be any filesystem impact, which means it shouldn't be failing on windows.

We need to get this fixed ASAP.

[rfermann]

I will look into this the next 2-3 days.

[rfermann]

I was able to identify the problem for the failing tests. In line 465 I'm using astNode.source.value to resolve the full file path of an import statement.

On macOS, the values in this field are looking like this: /Users/someUser/eslint-plugin-import/tests/files/no-unused-modules/file-added-4.js.js. With this value it is possible to resolve the full file path.
On Windows 10, the values are somehow quirky:

instead of C:\eslint-plugin-import\tests\files\no-unused-modules\file-added-4.js.js, which fails resolving.

Printing astNode.source to the console, the value looks different:
.
My assumption is, that the backslashes within the path are treated as escape characters. Is there any way to pass the strings without letting the escape characters taking effect?

[ljharb]

I wonder if that reflects an issue in the code setting the value then - not sure whether that’s ours or eslint itself.

[rfermann]

I could imagine that this is just the normal behavior on Windows systems, as all these systems are using the backslash instead the slash in the file path. So the value itself is a valid file path on Windows systems. Only JS doesn't like the backslashes in it when passing around the value.

A solution for this problem could be to use the raw field instead of the value field, as this field is correctly escaped.
I already tested this change on both Windows 10 and macOS and it is mostly working. Surprisingly another test is failing now which passed with the old code 😅

[ljharb]

@rfermann thanks for the fix; it'd be great tho to try to track down why there's a difference and fix that - possibly in eslint itself.

[rfermann]

I digged into that a bit. It seems, that this behavior is coming from the parser, not eslint itself. Babel-eslint is giving back the path in the same format on macOS and Windows (with slashes instead of backslashes), while espree is giving back different formats.

I haven't yet found the code causing this behavior, but I will stay on it.

[ljharb]

Thanks, that’s great - filing an espree issue once you can repro it would be awesome.