The path string returned when nan is imported in node 6 is wrong in some cases#601
The path string returned when nan is imported in node 6 is wrong in some cases#601amatas wants to merge 1 commit into
Conversation
|
Sounds like a bug in |
|
I speculate (but am not 100% sure) the realpath changes in v6 are responsible.
I wonder though if simply |
The latest implementation of the path.relative function of node v6 seems
to be broken when either of the "from" or "to" paths are in a network
resource of windows, removing the leading backslashes "\\" and returning
a wrong path [0].
The new approach employs the path.resolve function that returns the
absolute path to the nan headers and seems to work fine in the case of
node v6 running in a windows box.
Tests:
* Windows 10 with node 4.3.0:
c:\>node -e "console.log(require('path').relative('.','\\\\VBOXSRV\\vagrant'))"
returns: \\VBOXSRV\vagrant\
* Windows 10 with node 6.5.0:
c:\>node -e "console.log(require('path').relative('.','\\\\VBOXSRV\\vagrant'))"
returns: VBOXSRV\vagrant\
[0] nodejs#600
amatas
force-pushed
the
path_workaround
branch
from
bbe2ba0 to
1bf8e0e
Compare
Done!
I believe so, I've tested the method with the following results: |
|
Sorry, I pressed the wrong button |
|
I've done some tests with the |
3 participants
Addressing this: #600
With the old method to get the current directory of 'nan' module, the path isn't got properly when the parent path is in a shared resource:
vboxsrv\vagrant\NODE_MODULES\nan(which don't exists)with the new method the current directory is obtained correctly:
\\vboxsrv\vagrant\NODE_MODULES\nanThis change makes that packages like
bufferutilorrefare built correctly as they are able to get thenanheaders if the working directory is inside a network resource.