Mapped paths broken on Windows machines

[dcatoday]

Windows machines with mapped drives fail to find unit tests. If a C:\projects\test.js drive is mapped to H:\test.js, running jest unit tests will search for H:\test.js inside of C:\projects which will obviously fail. We noticed this behavior when we upgraded our jest to 24.x and after a lot of troubleshooting we see that the process.binding('fs') seems to be the culprit.

[SimenB]

I doubt this is the fix - this module exists almost entirely because of windows and its horrible handling of symlinks

[SimenB]

Does #39 fix the issue for you?

[dcatoday]

I see, I've pasted his code into my local node module and it comes back with the same error I'm trying to fix which is showing that it can't find the unit tests because of the mapped drive. The drive mapping and operating system are outside of my control as it's the setup for all devs at my company. I did look through the process.binding documentation and node.js docs seem to say that "process.binding() is for use by Node.js internal code only" and also that it is deprecated as of node 11. I wonder is it necessary at all to use it?
https://nodejs.org/api/deprecations.html#deprecations_dep0111_process_binding

[rominator1983]

I am running into a similiar issue over here using a RAM-disk. It seems to break in line 29:

Error: EISDIR: illegal operation on a directory, realpath 'M:\Some path'
    at Function.realpathSync.native (fs.js:1606:3)
    at realpathSync (M:\Some path\node_modules\realpath-native\index.js:29:28)
    at Object.<anonymous> (M:\Some path\node_modules\jest-resolve\build\index.js:106:48)
    at Module._compile (internal/modules/cjs/loader.js:1156:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1176:10)
    at Module.load (internal/modules/cjs/loader.js:1000:32)
    at Function.Module._load (internal/modules/cjs/loader.js:899:14)
    at Module.require (internal/modules/cjs/loader.js:1042:19)
    at require (internal/modules/cjs/helpers.js:77:18)
    at _jestResolve (M:\Some path\node_modules\jest-config\build\normalize.js:99:39)

I could fix it by doing this in line 29 instead. What do you think?

    try {
      return fs.realpathSync.native(filepath);
    }
    catch {
      return filepath;
    }

[SimenB]

I've published a v3 and deprecated it - all current releases of node supports fs.realpath.native now, so this module is no longer needed.

Jest 26 no longer depends on this module.