-
Notifications
You must be signed in to change notification settings - Fork 309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: pack:win
fails (silently) when node_modules path is >260 characters
#1228
Comments
pack:win
fails when node_modules path is >260 characters
pack:win
fails when node_modules path is >260 characterspack:win
fails (silently) when node_modules path is >260 characters
I thought that I had found a work-around (the silent failure of I tried:
🔥 However, the "./tmp/client/node_modules" directory structure does not match the project's Example of project's "node_modules" structure*This example shows that both "api" and "api-logs" dependencies have been hoisted out of the "@opentelemetry/auto-instrumentations-node" dependency and up to the top. Example of oclif's "tmp/my-cli/node_modules" structure*This example shows that the incredibly deep, classic "node_modules" directory structure has magically reappeared and highlights the longest file path! ⁉ How does oclif generate these "tmp" directories? It doesn't seem to use the already existing "node_modules" directory as-is... |
A lucky workaround for our specific project was to move the entire project to the shortest root path on disk as possible e.g. under "C:\src" with a short project directory name. |
Issue
The
makensis
command fails silently when building the ".nsi" file fails because of a "client" subdirectory path that is longer than 260 characters.Steps to replicate
yarn install
yarn oclif pack:win
makensis
failed due to the "MAX_PATH" issue described here)What is the current behavior?
The command that fails silently is located here:
oclif/src/commands/pack/win.ts
Lines 318 to 320 in 81222ca
The offending NSI configuration for copying the "client" directory contents is located here:
oclif/src/commands/pack/win.ts
Line 76 in 81222ca
A very similar issue is explained in the NSIS forums. However, the comments offer no resolution or further insight.
Also, a related, but completely different explanation of the issue can be found on StackOverflow.
The official Microsoft documentation for this behavior and the
[in] lpFileName
parameter.As well as a note on current Windows builds:
I attempted to modify the local source of Oclif's "win.ts" file including debugging the
const { stdout, stderr} = await exec(makensis ...)
command output.makensis stdout
makensis stderr
The "node_modules" directory structure and "context-helpers.js.map" file mentioned in the error do indeed exist and simply exceed the "MAX_PATH" issue that Microsoft has documented.
While debugging, I unsuccessfully attempted to modify the
File /r client
to instead readFile /r \\\\?\\client
as well asFile /r \\\\?\\.\\client
. Themakensis
command simply failed at that line with the error:While I am on Windows 11 and should not generally have this "MAX_PATH" issue (according to Microsoft's documentation). I also edited my local registry to explicitly enable long paths with the PowerShell command:
What is the expected behavior?
Oclif packaging for Windows works with long paths. The "node_modules" directory structure is rather infamous for lengthy sub-directories and file paths with a thread of Windows-specific issues.
The text was updated successfully, but these errors were encountered: