test-exclude should supply `nocase` to `minimatch` and `glob` when running on win32.
j03m opened this issue · comments
See description here: bcoe/c8#183
Capital vs lowercase driver letters can throw this check off as it is currently written.
CC: @bcoe
What about the other uses of minimatch and glob from index.js? Should they also provide nocase: true under Windows?
That is a good question. This is the one place I saw it become an issue in my project on windows, but let me examine the others. Windows paths are case insenstive so where we do comparisons on paths it seems prudent we do the same. But I don't know this lib that well. Let me examine the usages.
For an example by default test/** is excluded from coverage (ignored). Currently Test/file.js will not be excluded, even on Windows. I'm not sure if this is correct behavior. I'm also unsure what happens if we end up with inconsistent casing of process.cwd() vs the cwd option of test-exclude. Like what if test-exclude is created with cwd of c:\project but then we try to check if C:\Project\index.js should be instrumented.
Can we just take an optional minimatch key and pass on the options to minimatch? Would that be overkill?
I'd prefer not to as we'd then need to expose the option to nyc. I'm leaning towards thinking it would be better to set the option per platform.
Finally had a chance to look over the code I think you're correct that nocase should probably be supplied to glob and minimatch anywhere we use it when running on windows. I wrote up a PR where these two tests will pass, but I can't submit until I get approval from my company (should be soon tho).
Basically the tests below will pass, where as they will fail on current master. To be able to test on mac I also supplied a forceWin32 option that will toggle the nocase flag.
t.test('should handle case insensitive paths on win32', t =>
testHelper(t, {
options: {
exclude: undefined,
include: ["boo.js"],
forceWin32: true
},
no: [],
yes: ['BOO.js']
})
);
t.test('should handle case insensitive drives on win32', t =>
testHelper(t, {
options: {
cwd: 'C:\\project',
forceWin32: true
},
yes: ['c:\\project\\foo.js']
})
);
***Edited test
Changed title to reflect additional scope
I ended up removing that bit on forceWin32 and kept with checking the platform in the tap tests. Running something like path.resolve("c:\projects", "c:\projects\foo.js") on osx resolves to something like/Users/..../C:\projects/c:/projects/foo.js :/ but I ran the tests on windows and they pass.
That said, if we don't run win32 as part of CI then there is always going to be a risk of breaking this there. Any ideas how we could test both on a posix os?
Maintaining CI for both Win32 and POSIX is definitely a priority for this module. If Travis-CI were to drop support for Win32 we would immediately investigate other options and implement one of them. I think creating a forceWin32 option is unnecessary and my vote is to avoid adding test options to the production code.
My suggestion would be to make is-outside-dir-*.js provide named exports:
module.exports = {
isOutsideDir(...) {
// code clipped
},
minimatchOptions: {
dot: true,
nocase: true // in is-outside-dir-win32.js only
}
}This will avoid adding a platform dependent conditional to index.js so we will maintain 100% coverage without adding any istanbul ignore hints.
Then add platform dependent testing:
if (process.platform === 'win32') {
// verify that some Win32 paths with different case match
t.test('uses case insensitive matching', t => { ... });
} else {
// verify that some POSIX paths with different case do not match
t.test('uses case sensitive matching', t => { ... });
}We will need testing for both shouldInstrument and glob methods.
Checking in: I made your suggested changes locally, still just waiting on legal approval to submit. :/