Closed henryli333 closed 5 years ago
The path might not be malformed.
On the terminal,
dir <that\path>
shows an existing file.
Similar situation here: https://stackoverflow.com/questions/49729061/windows-10-existing-binding-node-file-cannot-be-found-when-running-jest
Possibly something to do with native(?) libraries.
Interesting, I did not expect that \?\ would be valid pathing! That means my assumptions have been wrong, and we need to look at other possible cause of this.
Update: Found out what \\?\ does: https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#maximum-path-length-limitation
This means that \\?\ has nothing to do with our issue.
Changing to Large as this task is time-consuming but doesn't require a lot of changes and refactor to code.
The code compiles successfully and runs fine when the electron version stated in .npmrc is 1.2.8, I tried to change it to 1.8.8 and the same error message is shown when the app load up, the compiling is also not working on my pc (windows 10). Hope it helps solving the problem
The code compiles successfully and runs fine when the electron version stated in .npmrc is 1.2.8, I tried to change it to 1.8.8 and the same error message is shown when the app load up, the compiling is also not working on my pc (windows 10). Hope it helps solving the problem
Compiling the application should be fixed in master (see #145) by rolling nodegit back to 0.13.2. I think the problem here is that you can't pass tests in windows as it can't find a module as suggested above (yet to find a fix). I'm on mac so I can't extensively test it right now unfortunately :(
A lot of issues regarding nodegit on Windows has been traced to be due to the application attempting to find the nodegit.node file using a malformed path. Examples can be seen below, where the paths begins with
\\?\
.This issue currently prevents changes made in #137 to compile and run properly on Windows, and is preventing jest from running certain test suites on Windows (which PR #145 is attempting to resolve).
This seems to be a root cause of many issues Windows users are experiencing; finding the cause of this would likely make the project more robust moving forwards.