在 Windows 10 / Webstorm 使用 WSL 2 运行项目

[lmk123]

开发划词翻译的服务端时，我是直接在 Windows 10 上开发的，但会遇到一些问题，最不方便的就是终端命令不一样。比如为了删除某个文件，在 Bash 里用的是 rm file，但在 Windows 10 的 PowerShell 里就不一样，我目前的做法是用 shx，但这样饶了一圈比较麻烦。

我今天突然想到，是不是可以在开发时让代码直接跑在 Windows 10 的 WSL Ubuntu 里？试了一下确实是可以的。

配置 WSL 让项目能在 Ubuntu 里运行

以划词翻译的服务端项目为例，假设我的项目地址在 C:\Users\xxx\hcfy-backend，那么首先在 PowerShell 打开这个地址，然后输入 wsl 就能进入 Ubuntu 里的这个地址了，如下：

PS C:\Users\xxx\hcfy-backend> wsl
xxx@DESKTOP:/mnt/c/Users/xxx/hcfy-backend$ ls
package.json   node_modules ...

但是在 Ubuntu 里输入 docker -v 会提示找不到 docker 命令，需要先在 Docker Desktop 里开启对 WSL 2 的支持，然后再运行 docker -v 就成功了：

xxx@DESKTOP:/mnt/c/Users/xxx/hcfy-backend$ docker -v
Docker version 20.10.0, build 7287ab3

然后，为了让项目能在 Ubuntu 环境下开发，我还在 Ubuntu 里做了这些事情：

• 安装 Node.js
• 安装 Yarn

经过以上几个步骤之后，就可以正常在 Ubuntu 里使用 yarn、docker 和 docker-compose 了，但接下来还有两个问题要解决。

Ubuntu 里的项目地址变得很长

在经过以上几个步骤之后，在 PowerShell 里输入 wsl 之后，进入到的 Ubuntu 里的地址变得很长：

PS C:\Users\xxx\hcfy-backend> wsl
xxx@DESKTOP:/mnt/wsl/docker-desktop-bind-mounts/Ubuntu/8a5edab282632443219e051e4ade2d1d5bbc671c781051bf1437897cbdfea0f1$ ls
package.json   node_modules ...

在这个目录下的文件跟 hcfy-backend 目录下的是一样的，但是我希望文件地址应该是正常的 /mnt/c/Users/xxx/hcfy-backend，后来在这里找到了答案：

Long working directory in bash when Docker desktop is running in WSL2

简单来说就是要先启动 Docker Desktop，然后再用 wsl 进入 Ubuntu，就不会有这个问题。

无法通过 yarn 运行命令

同一条命令，直接在 bash 里可以运行，但如果写到 package.json 里的 "scripts" 里用 yarn 运行就会报错。

例如，直接在 bash 里运行 docker-compose -v 是可以正常输出 docker-compose version 1.27.4, build 40524192 的。

但如果我把这条命令写在了 scripts 里：

"script": {
  "t": "docker-compose -v"
}

然后用 yarn t 运行就会报错：

yarn run v1.22.5
$ docker-compose -v
error Couldn't find the binary docker-compose -v

我谷歌到了这条 issue 下的一个评论，于是在 Ubuntu 里运行了这条命令：

$ yarn config get script-shell
C:\Program Files\git\bin\bash.exe

然后我尝试将 script-shell 直接设置成 bash 之后就成功了：

xxx@DESKTOP:/mnt/c/Users/xxx/hcfy-backend$ yarn config set script-shell bash
yarn config v1.22.5
success Set "script-shell" to "bash".
Done in 0.05s.
xxx@DESKTOP:/mnt/c/Users/xxx/hcfy-backend$ yarn t
yarn run v1.22.5
$ docker-compose -v
docker-compose version 1.27.4, build 40524192
Done in 0.37s.

webpack --watch 失效了

在 Ubuntu 里使用 webpack --watch 后，发现在 Windows 10 里改变了这些文件并没有触发 Webpack 的重新编译。

有两种解决方案：

1. 设置 watchOptions.poll 为 true
2. 将项目的文件存放在 WSL 的文件系统。

第一种方案最为简单便捷，所以我一开始用了第一种，但是监听文件改变似乎不太及时，又折腾成了第二种。

第二种方案稍微有点复杂……

在 WSL 里，Windows 的文件被存放在 /mnt 下，例如，Windows 里的 C:\Users\xxx 在 WSL 里是 /mnt/c/Users/xxx。但是如果我们将项目的文件存放在 /home/xxx/ 下面，那么 watch 是可以正常检测到文件变化的，而且使用 WSL 的文件系统还可以让运行速度提升，见 Place your Linux files in your Linux root file system。

我按照这些步骤让项目在 WSL 的文件系统下运行：

1. 进入 WSL 后，将项目 clone 到 /home/xxx/porjects。最好是给 GItHub 账号配置 SSH 的克隆方式。
2. 回到 Webstorm，打开项目时选择 \\wsl$\Ubuntu\home\xxx\projects\项目文件夹。其中 \\wsl$ 是跟 C:\ 平齐的，如果打开项目时没有 \\wsl$，那么可能需要先在 WSL 里运行一下 explorer.exe .。其余需要加载文件的地方（例如开发 Chrome 扩展时需要载入解压的扩展文件夹）也加载 \\wsl$ 下的文件即可。

目前这种方式的使用感受：

• 文件系统速度真的很快。启动 Webpack 的时间感觉比在 Windows 上少了三分之一。
• 前几次从 Windows 文件系统进行对 WSL 文件系统的操作很慢很慢，例如在 WebStrom 里用 Git 回滚对文件的修改，就花了大概 3 分钟时间，但是之后就很快了

在 WebStorm 里修改一些 WSL 相关的配置

项目配置好了，但是 WebStorm 里使用的终端还是 Windows 10 默认的 PowerShell，需要改变这些设置：

1. 将“工具” - “终端” 里的“Shell 路径”里填写 “wsl.exe”
2. 将“语言和框架” - “Node.js 和 npm” 里的“节点解释器”（这里 Webstorm 翻译有误，英文是 Node.js Interceptor）选择“Ubuntu /usr/bin/node”，“包管理器”选择“yarn /usr/share/yarn”
3. （可选）将“编辑器” - “代码样式”里的“行分隔符(新文件)”改成 \n；已经有的文件可以在选中文件夹后，通过菜单栏中的“文件” - “文件属性” - “行分隔符” 进行批量替换。

这就是在 WebStorm 里需要做的全部设置了。

如果你想让之前运行在 Windows 10 上的其它 WebStrom 项目也切换到 Ubuntu 里运行，那么这些 WebStrom 项目也需要进行上面两步的设置，不然在 WebStrom 里会运行不起来。

在 WebStorm 里编辑 WSL 里的项目的另一种方式：远程连接

前面的方法使用 WebStorm 直接打开了 WSL 里的项目目录，然后修改了“终端”和“Node.js 解释器”，这种情况下，WebStorm 是直接编辑 & 运行 WSL 里的项目的。

现在，WebStorm 支持通过另一种方式编辑 WSL 里的项目，即“远程连接”。

这个功能就如同它的名字一样，它实际上是在 WSL Ubuntu 里安装了一个控制端，然后在 Windows 里以“远程控制”的方式来编辑 & 运行 WSL Ubuntu 里的项目。它们之间通过网络连接。

这样做有一些好处：

• 比起前面我自己摸索的方式，“远程连接”里专门有连接到 WSL 的选项，所以这应该是目前官方推荐的方式
• “远程连接”真正隔离了 Windows 和 Ubuntu 环境。
  • 前面我自己摸索的方式是“用 Windows 里的 Webstorm 直接编辑 & 运行 WSL Ubuntu 里的项目”，但这种方式能成功是因为有 WSL 在中间做了一个桥梁。举个例子，假设我们要用 Windows 里的 Webstorm 编辑另一台电脑里的 Ubuntu，那么没了 WSL 这个桥梁，就做不到了，此时，“远程连接”就是一座新的桥梁。
  • 远程连接的情况下，WebStorm 意识到自己是在一个 Ubuntu 环境内。所以，无需重新配置“终端”、“Node.js 解释器”、“行分隔符”等选项，WebStorm 会自动适配 Ubuntu 环境。

但“远程连接”目前使用下来也有一些不好的点：

• 启动慢 & 编辑速度慢。
  • 由于是远程连接，所以初次启动会需要在 WSL Ubuntu 里下载大概 1 GB 的控制端，之后每次打开 WSL Ubuntu 里的项目时，都要先启动 WSL Ubuntu 里的控制端。当然，也可以选择让这个控制端始终在 WSL Ubuntu 里运行，让下次启动速度快一些，但我个人不希望在不写代码的时候，还在 WSL Ubuntu 持续运行这个控制端。
  • 使用上感觉卡卡的，在滚动文件内容时尤为明显。
• 编辑器不是 WebStorm。“远程连接”使用的编辑器是一个新的编辑器，目前我使用下来有以下不同：
  • WebStrom 的汉化包插件几乎已经汉化了 WebStorm 的所有文本，但是这个新的编辑器虽然也安装了这个汉化包插件，但只有部分文本被汉化了
  • WebStrom 的新 UI 会在单击一个文件的时候显示预览，当单击另一个文件时，这个预览会变成新的内容，而这个新编辑器单击就直接是打开，单击另一个文件会另外再打开

总的来说，使用体验还是不如用 WebStorm 直接加载 WSL Ubuntu 里的项目。