如何为每个项目单独指定NodeJs版本

本文首发于我的博客 YILS's Blog，首发地址：如何为每个项目单独指定NodeJs版本 (yils.blog)

前端技术日新月异，始终朝气蓬勃，新的框架层出不穷，有时候 Node.js 几乎每周都会发布新版本，现在更出现了 Bun 和 Deno 等 Node.js 的有力竞争者。

为什么需要为每个项目单独指定一个 Node.js 版本？

这是你这么做之前首先要明确的问题。

也许你遇到过以下情况：

• 我想要尝鲜 Node.js v22.x 所带来的新特性
• 我要给 ArcoDesign 贡献一波，但运行它要求 Node.js 版本为 v18.x
• 团队成员 Node.js 版本不统一： 守旧派用 v12.x、保守派用 v14.x、激进派用 v18.x，突然某天老板让我去维护守旧派负责的项目，运行后由于Node.js版本不一致直接报错
• 我需要同时运行两个项目，但项目需要的 Node.js 版本不同
• 我是项目的主要维护者，我希望为项目强制限制node和npm版本，防止lock文件冲突
• …

这个时候就轮到版本管理工具大展拳脚的时候了。

都有哪些成熟的 Node.js 版本管理工具？

我们可以从 Node.js 官网看到官方推荐的版本管理工具：

Node.js — Installing Node.js via package manager (nodejs.org)

其中，最流行的是 nvm、n、fnm。（由于 n 和 nvm 功能和指令相似，但不支持windows，所以这次不对其做评测）

此外从下面这篇 v2ex 贴中大家还提到了一些其他的版本管理工具/方案：

大家在开发过程中是如何管理多个项目不同的 NodeJS 版本的? - V2EX

包括：volta、asdf、webstorm

下面我们来详细对比一下

nvm/nvm-desktop

nvm 已经是大家熟知的版本管理工具了，但仍然在此挂一下 Github 地址：

nvm-sh/nvm: Node Version Manager(Linux/Mac)

coreybutler/nvm-windows

值得一提的是，nvm 的 Linux/Mac 版本和 Windows 版本是两个功能相似的由不同开发者并行开发的独立工具。

使用方法也非常简单：

# 查看可用版本
nvm list available
# 安装指定版本
nvm install 16
# 使用指定版本
nvm use 16
# 列出本机已安装的全部版本列表（带*的为当前全局默认版本）
num list

当项目繁多复杂时，问题也随之而来，使用 nvm 虽然完成了多版本管理，但是默认版本只能有一个，所以很多时候，在用 vscode 打开不同项目的时候，还需要用 nvm use 来切换不同的版本使用。

显然经常这样操作很麻烦，也容易忘记什么项目用什么版本，而且还有一个致命问题——无法同时运行两个不同版本的项目。

此前我也一直苦于习惯了 nvm 的顺滑操作，却没办法在切换项目时自动切换版本且同时运行的问题，但如今一个新工具的诞生解决了这个问题：

1111mp/nvm-desktop（提示：使用nvm-desktop无需安装nvm）

nvm-desktop 这个项目目前 star 还不多，但提供了跨平台的 nvm 图形管理界面，使用 electron 开发，且底层使用 rust 编写的命令行工具 nvmd-command 提供了智能识别项目 node 版本，自动切换和同时运行多个版本的能力。

根据 nvm-desktop 开发者解释以及我的深度体验，其可以为项目单独指定你想要的 Node 的版本。

或者你也可以通过命令行为你的项目指定nodejs版本 nvmd use node_version --project。

这样做会在项目的根目录下会添加一个文件：.nvmdrc，内容为你选择的 Node 的版本号，如果未添加此文件则加载为全局设置的 Node 的版本号。

且如果团队成员都安装了 nvm-desktop 则他们也可以在进入项目时无缝切换到指定版本。

fnm

fnm 是一款快速简单的 Node.js 版本管理器，使用 Rust 构建。其 Github 地址：

Schniz/fnm: 🚀 Fast and simple Node.js version manager, built in Rust (github.com)

由于 fnm 使用 Rust 构建，运行速度很快，不会和 nvm 一样在查询版本列表时卡住几秒。

fnm 功能：

• 设置全局默认版本
• 为版本设置别名，以便随意调用
• 为当前 shell 窗口临时切换 node 版本
• 使用 .node-version 文件为项目配置默认版本以自动切换

对于 fnm 的安装教程可以查看这篇：

Windows 上使用 fnm 安裝 Node.js - Oldest Dream

可惜的是 fnm 没有详细的文档，虽然指令并不多。

volta

volta 也使用 Rust 构建。Github 地址：

volta-cli/volta: Volta: JS Toolchains as Code. ⚡ (github.com)

不同于 nvm 和 fnm 的软链替换原理， volta 会代理 node、npm 等命令，是更广义上的 toolchain manager。

除了 Node 其还能管理 npm、yarn 等，目的就是为了做到不同的项目里能有完整且版本隔离的 toolchain。

volta 功能：

• 设置全局默认版本
• 为全局包固定 node 版本
• 使用 package.json 文件为项目配置默认 node 版本和 npm 版本以自动切换

为项目固定版本时 volta 会在 package.json 中添加以下内容：

"volta": {
  "node": "12.20.2",
  "yarn": "1.19.2"
}

值得一提的是 volta 官网有非常详尽的文档

docs.volta.sh/

不过也需要注意，volta 的实现方式决定了其对 node 环境隔离方面可能有所欠缺。

asdf

asdf 是一个强大的工具，目的是确保团队的任何工具都可以使用完全相同的版本， 核心在 Shell 配置中设置好之后，通过插件系统来支持各种工具的版本管理。它就像 gvm 、 nvm 、 rbenv 和 pyenv （以及更多）合而为一。

关于项目中所有的工具版本定义都会包含在一个文件 .tool-versions 中，以支持自动切换。

可惜的是，它不能直接支持 windows。

webstorm

作为一款合格的 IDE ，而不是 vscode 这样的轻量化编辑器， webstorm 继承了 jetbrains 家的传统，用过 IDEA 或者 pycharm 的朋友应该知道，其可以为每个项目单独指定运行环境，方便的下载和管理各种环境版本，还能对项目智能重构，功能非常强大。

但它也有缺点，在配置较低的电脑上，敲写代码有粘滞感，占用内存较大，对小项目并不友好，其又是付费产品，不如 ts 编写且开源的 vscode 得天独厚的丰富插件生态等，这就导致大量前端程序员更喜欢使用 vscode。

当然我还是很推荐你使用 webstorm 的，因为它在大型工程中表现相当出色。👍

我该选择哪个？

选择最合适的 Node.js 版本管理工具应结合你的开发需求、团队协作情况以及个人偏好。比如：

• 如果你在团队环境中工作，需要一个稳定、跨平台且有友好图形界面的工具，那么我大力推荐 nvm-desktop。尽管其社区不如 nvm 那么活跃，但它提供了更现代的用户体验，安装使用都极其方便，并支持自动切换和多版本同时运行。

• 对于那些寻求极快性能以及简洁命令行体验的开发者，fnm 可能是最好的选择。基于 Rust 构建意味着其性能卓越，对于那些使用 nvm 时感到沮丧的开发者来说是一次新的尝试。

• 如果你不仅需要管理 Node.js 版本，还需要管理 npm、yarn 等 Javascript 工具链，volta 也许是最合适的选择。Volta 的理念是提供更广义的工具链管理，确保项目的环境一致性。

• 如果你的团队项目语言复杂，需要一个通用的版本管理工具，旨在管理多种语言的版本，例如 Ruby、Python、Elixir 等，asdf 将是你的好帮手，它还有好用的 vscode 插件。然而需要注意的是，它并不直接支持 Windows，可能需要额外的配置。

• 最后，如果你要求 IDE 强大、全面，不介意付费且对资源占用量不敏感，可以选择 WebStorm。它支持项目环境的智能管理和复杂重构等高级功能，并有着优良的用户体验。

如何强制限制项目node版本

使用package.json里的engines字段指定所需的Node.js版本。比如：

"engines": {
  "node": ">=14.0.0"
}

这样，当使用不合适的Node版本运行npm安装命令时，会提示版本不兼容的警告。

但这样并不会强制结束安装进程，我们可以利用 preinstall 或 prerun 等生命周期来运行一个检查脚本，以强制结束错误版本的安装操作，例如：

"scripts": {
  "preinstall": "npx check-fe-env"
}

"scripts": {
  "preinstall": "npx only-allow pnpm"
}

结语

还有用 docker、远程开发等方式统一项目版本，但对团队素质或资源要求较高，可以自行探索一下。