resolve result is inconsistent with require.resolve if windows virtual drive is used

[pos777]

I'm researching the rollup/rollup#4260 issue and found that the resolve and the require.resolve results differ in windows virtual drive (subst).

To reproduce run the following index.js script:

const resolve = require('resolve');

console.log('require.resolve: ' + require.resolve('./index.js'));
console.log('resolve.sync:    ' + resolve.sync('./index.js', { basedir: __dirname, preserveSymlinks: false }));
resolve('./index.js', { basedir: __dirname, preserveSymlinks: false }, (err, res) => {
    if (err) console.error(err);
    else console.log('resolve:         ' + res);
});

in the following way:

> npm install resolve
> subst X: .
> X:
> node index.js

Output:

require.resolve: X:\index.js
resolve.sync:    C:\repo\index.js
resolve:         C:\repo\index.js

[ljharb]

Which version of resolve are you using? v1 is "latest", but there's a v2 prerelease that's worth trying as well.

It's possible that the preserveSymlinks option (which v2 changes the default of) is the difference you're seeing.

[pos777]

The result is the same for v1.22.0 and v2.0.0-next.3.
The preserveSymlinks option is set explicitly in script to ensure that it is false.
I have added the index.js.link file to the test (via mklink). Result for it is inconsistent too:

v1.22.0

X:\>node index.js

require.resolve: X:\index.js
resolve.sync:    C:\repo\index.js
resolve:         C:\repo\index.js

require.resolve (link): X:\index.js
resolve.sync (link):    C:\repo\index.js
resolve (link):         C:\repo\index.js.link

X:\>npm ls resolve
null@ X:\
`-- resolve@1.22.0

v2.0.0-next.3

X:\>node index.js

require.resolve: X:\index.js
resolve.sync:    C:\repo\index.js
resolve:         C:\repo\index.js

require.resolve (link): X:\index.js
resolve.sync (link):    C:\repo\index.js
resolve (link):         C:\repo\index.js.link

X:\>npm ls resolve
null@ X:\
`-- resolve@2.0.0-next.3

[pos777]

It seems that the fs.realpathSync.native and the fs.realpath.native functions cause the behavior:

resolve/lib/sync.js

Line 9 in 4e183d7

var realpathFS = fs.realpathSync && typeof fs.realpathSync.native === 'function' ? fs.realpathSync.native : fs.realpathSync;

resolve/lib/async.js

Line 9 in 4e183d7

var realpathFS = fs.realpath && typeof fs.realpath.native === 'function' ? fs.realpath.native : fs.realpath;

Node's loader uses the fs.realpathSync if I look at correct place:

https://github.com/nodejs/node/blob/26846a05e2ac232742e6a0bfaa7baac5e86a015b/lib/internal/modules/cjs/loader.js#L394-L398

In the test scenario these functions give the following result:

X:\>node index.js

fs.realpathSync (./index.js):        X:\index.js
fs.realpathSync.native (./index.js): C:\repo\index.js
fs.realpath (./index.js):            X:\index.js
fs.realpath.native (./index.js):     C:\repo\index.js

As I see native functions were introduced to improve performance (#217).
If there is not another reason and there are performance tests I can compare realpath vs realpath.native.

[ljharb]

If the native function gives the wrong answer on windows, then we could certainly avoid using it only on windows.

[ljharb]

Fixed by #284.

[pos777]

@ljharb, thank you! Is it possible to publish a new patch (v1.22.1) with the fix?

[ljharb]

I will do so this week.

[pos777]

Hello @ljharb, any updates?

[ljharb]

v1.22.1 is released.