Uh oh!
There was an error while loading. Please reload this page.
Revert "windows: Add preliminary WSL support for npm and npx" - #527
Revert "windows: Add preliminary WSL support for npm and npx"#527craigloewen-msft wants to merge 1 commit into
Conversation
This reverts commit 3471d52.
craigloewen-msft
commented
Nov 27, 2019
Tagging @infinnie so this is visible to you as you're the author of the original commit! |
Thanks but no, it did not prevent NPM for Linux from being run. I had wished that it could fall back to the Windows command prompt when the Linux executable is not found. When the corresponding Linux version exists, however, it would be in a position within This, if implemented, would prevent NPM for Windows from running into an error when executed inside WSL. |
darcyclarke
commented
Nov 27, 2019
@craigloewen-msft@infinnie I've added this PR to the agenda of our Open RFC call happening later today; I encourage you both to join if you'd like to discuss the ideal solution moving forward: npm/rfcs#70 |
craigloewen-msft
commented
Nov 27, 2019
Thanks! I'll join the call. |
craigloewen-msft
commented
Nov 27, 2019
For more context, if I run these commands using the Linux binaries targeting a project in my Linux file system in WSL, it succeeds: However, if I use the Windows version of npm to target the same project in my Linux file system, I receive an error since CMD is unable to access these Linux files. Thanks for your help! |
Hello. It was not meant to replace the Linux version. Just in case the Linux one is not installed and Windows files are what need to be handled. |
* refactor: consolidate output hygiene into output.rs Introduce src/output.rs that consolidates: - sanitize_for_terminal (upgraded: now also strips bidi overrides, zero-width chars, directional isolates, line/paragraph separators) - reject_dangerous_chars (renamed from reject_control_chars) - is_dangerous_unicode predicate - colorize + stderr_supports_color (NO_COLOR + TTY detection) - status/warn/info stderr helpers (auto-sanitize) Migrate existing callers via re-exports from error.rs and validate.rs. Fix watch.rs: - Sanitize raw API error body in eprintln (was high-risk injection vector) - Replace 3 inline ANSI escape codes with colorize() for NO_COLOR support Fix triage.rs: - Sanitize user --query string in no_messages_msg output * refactor: remove re-export indirection, import directly from output Update all 10 caller files to import sanitize_for_terminal directly from crate::output instead of going through crate::error re-exports. Remove pub(crate) re-exports from error.rs and validate.rs. * fix: use char::is_control() in reject_dangerous_chars for C1 coverage Address PR review: the manual (c as u32) < 0x20 check missed C1 control characters (U+0080-U+009F), including CSI (U+009B) which can inject terminal escape sequences. Using char::is_control() covers both C0 and C1 ranges. Add test for CSI rejection. * fix: validate ansi_color in colorize() to prevent injection Defense-in-depth: only emit ANSI escape codes when ansi_color contains exclusively ASCII digits. Falls back to plain text if an invalid color code is passed. --------- Co-authored-by: jpoehnelt-bot <jpoehnelt-bot@users.noreply.github.com>
This reverts commit 3471d52.
What / Why
From my understanding, this change enables npm to detect that it is running inside of WSL, and instead of running the Linux version of npm, it will run the Windows installed version of npm. Would you be able to revert this change?
The reasoning behind this is that this could cause performance and compatibility issues for npm. Users in WSL would be expecting to use the Linux version of npm, and instead routing the command to target the Windows version of npm could cause unexpected problems.
I'm happy to dive into more detail on the reasons why, and thank you for thinking about WSL when you made this change! :)