我之前在 Windows 上安装了带有可执行文件的 Node.js(所以在 PowerShell 上工作),我错了吗?
不一定,一定是“错误的”,但它可能是问题的一部分。但是你肯定是正确的质疑它并在你的帖子中提供它作为一个关键细节!
虽然 WSL 可以发射Windows 可执行文件,请记住那些 Windows 可执行文件(在这种情况下为npm)通常只了解Windows路径、进程、环境变量等。
npm 在 Windows 版本的 Node 上有点不寻常,我想。它提供了一个 Bash shell 脚本,这实际上是您在 WSL 下运行 npm 时所调用的。该 shell 脚本最初是为 Cygwin 和 Git Bash 设计的,但我看到 Node 最近也为 WSL 添加了检查。在此之前,即使是(Windows 版本的)npm 本身在 WSL 下也会有问题。
但是,无论他们是否已修复 npm 以在 WSL 下工作,您都会遇到下一个级别的问题,因为 Angular 尚未修改 ng 以检测它何时在 WSL 下运行。
没有深入研究源代码,ng 将看到它在 Windows 版本的 Node 下运行,并尝试使用 Windows 工具和路径。在我在 WSL 下的测试中(使用 Windows 版本的 Node/npm),似乎发生的是 ng new project 尝试启动 CMD.exe。由于是在 Windows 版本的 Node 下运行,自然会假定 CMD.exe 可用。
确实如此,但是从 WSL 内部启动 CMD.exe 将尝试以 UNC 路径(\wsl$<distroname>path ocurrentprojectdir 或 \wsl.localhost...)启动。 CMD 不支持 UNC 路径,因此它默认为 Windows 目录本身,我得到:
EPERM: operation not permitted, mkdir 'C:Windowsproject'
当你得到一个不同的错误,可以肯定的是,它几乎肯定与这个根本问题有关。
长话短说,请参阅我在问题中的建议,How to organize programming languages and libraries in WSL and Windows 10。
总结一下,在使用开发工具时,要么:
- 使用 Windows 版本的工具链(编辑器、命令行、SDK、工具等)
- 或使用工具链的全 Linux 版本。
但是,请特别注意 Node。你能够安装:
- 当您使用 Windows 工具时的 Windows 版本的 Node
- 使用 WSL 工具时的 Linux 版本的 Node
但是当你在 WSL/Linux 中运行时,确保npm 和node 的Linux 版本出现在路径的最前面,在Windows 版本之前.这又是因为 Windows 版本提供了该 shell 脚本。如果 Windows 版本在您的 Linux PATH 中的 Linux 版本之前出现,那么您将继续遇到问题,因为 Windows npm 将在 WSL 下被调用(就像现在一样)。