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

Add fix for Windows Subsystem for Linux #1786

Merged
merged 1 commit into from
May 30, 2020
Merged

Add fix for Windows Subsystem for Linux #1786

merged 1 commit into from
May 30, 2020

Conversation

manuth
Copy link
Contributor

@manuth manuth commented May 29, 2020

This PR will add support for Windows Subsystem for Linux.

Windows Subsystem for Linux seems to have quite a weird treatment with file and directory-names.
While directories are case-sensitive (directory ./tests exists while ./TeSts doesn't), files don't seem to be (both reSOLVE.js and resolve.js exist).

This PR adds WSL-support by checking whether both directories and files are case-sensitive before setting CASE_SENSITIVE_FS.

@ljharb ljharb added bug package: utils eslint-module-utils package labels May 29, 2020
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Can you provide a test that would fail without this fix?

@manuth
Copy link
Contributor Author

manuth commented May 29, 2020

https://github.com/benmosher/eslint-plugin-import/blob/3f46ccfe203fa5aad5767699df339a9b2f0294e3/tests/src/core/resolve.js#L165-L186

These tests fail when running npm tests on WSL without this fix being applied.
Is there some way to put this into a unit-test?

@coveralls
Copy link

coveralls commented May 29, 2020

Coverage Status

Coverage increased (+2.6%) to 97.741% when pulling 8118170 on manuth:wsl-fix into 62b554b on benmosher:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.738% when pulling 4619037 on manuth:wsl-fix into 3f46ccf on benmosher:master.

3 similar comments
@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.738% when pulling 4619037 on manuth:wsl-fix into 3f46ccf on benmosher:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.738% when pulling 4619037 on manuth:wsl-fix into 3f46ccf on benmosher:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.738% when pulling 4619037 on manuth:wsl-fix into 3f46ccf on benmosher:master.

@ljharb
Copy link
Member

ljharb commented May 29, 2020

ahhh so the existing tests do cover it, but we're not actually running tests on WSL - just on normal windows.

If you already know how to add that to appveyor or travis, then that would be amazing, but if not, that is also OK and we can punt it to later.

appveyor.yml Outdated Show resolved Hide resolved
@manuth
Copy link
Contributor Author

manuth commented May 30, 2020

Ouch... looks like apt just invoked a form which requires user-interaction... might take a while until all the jobs run into a timeout :/

@manuth
Copy link
Contributor Author

manuth commented May 30, 2020

@ljharb is it possible to run console.log(require("./utils/resolve").CASE_SENSITIVE_FS) on appveyor for test-purposes?

Though WSL works now, the npm-tests still fail which is very strange.
An error about the case-sensitive tests is reported even if they actually should be skipped (cause of CASE_SENSITIVE_FS being set to true)

@manuth
Copy link
Contributor Author

manuth commented May 30, 2020

@ljharb as expected, "CASE_SENSITIVE_FS" is true, but still the case sensitive tests aren't skipped.

Any idea what might be buggy here?
Probably a function binding problem?

@manuth
Copy link
Contributor Author

manuth commented May 30, 2020

@ljharb I can't help it - CASE_SENSITIVE_FS definitely is true and still the tests aren't skipped...
Anyways the WSL jobs are up and running now.

Any other idea on how to fix it?

@manuth
Copy link
Contributor Author

manuth commented May 30, 2020

@ljharb sorry for spaming you with notifications
I found out what's causing the problem.

When only running npm run tests-only, pretest isn't executed, which actually would symlink ./utils as module eslint-module-utils. The fact that pretest isn't executed causes npm to use eslint-module-utils from the npm-registry instead of ./utils.

Should I change the .travis.yml and appveyor.yml files to execute pretest

@ljharb
Copy link
Member

ljharb commented May 30, 2020

Yes, that sounds like a great idea.

@manuth
Copy link
Contributor Author

manuth commented May 30, 2020

@ljharb Alright, made it!
The WSL-jobs now should pass.
After merging this PR I could create another one for this here, if you want:
https://github.com/benmosher/eslint-plugin-import/blob/3f46ccfe203fa5aad5767699df339a9b2f0294e3/appveyor.yml#L40-L42

After doing so, this project's fully Windows compatible (using WSL, at least)

@ljharb
Copy link
Member

ljharb commented May 30, 2020

Yes, that would be amazing, thanks. I don't have any Windows machines to test, so Appveyor is the only validation this project really has.

@ljharb
Copy link
Member

ljharb commented May 30, 2020

Looks like node 8 and 14 "Native" tests are still failing. I've rebased this (and squashed and added a changelog entry), so let's see what happens.

 - Update appveyor-config to include wsl
@manuth
Copy link
Contributor Author

manuth commented May 30, 2020

Looks like Babel is causing trouble
I'll try to update it and create a PR

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM pending tests

@ljharb
Copy link
Member

ljharb commented May 30, 2020

hmm, now all the native tests are failing - but on the coveralls step, all the tests are passing on node 10 and 12 (node 14 still fails with "Cannot find module 'C:\projects\eslint-plugin-import\node", and node 8 still fails with a ton of "Path must be a string. Received undefined" errors)

However, all those tests were already failing the same way on master, so this still seems worth landing for now, as-is.

@ljharb ljharb merged commit 8118170 into import-js:master May 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug package: utils eslint-module-utils package
Development

Successfully merging this pull request may close these issues.

3 participants