Nvm-windows: 不适用于 .nvmrc

.nvmrc从未被支持。 这是 nvm 特有的功能，而不是 Windows 的 NVM。

@coreybutler我来自灾难责任项目，我们有一些开发人员使用 Windows 并且无法利用.nvmrc 。 我们开始为我们的志愿 Web 开发人员采用nvm-windows ，我希望您重新考虑支持.nvmrc 。 这是我们使用 .nvmrc 的站点。

@inunotaisho26 - 从根本上说，这个项目专注于准备 Node，就好像它的安装方式与没有版本管理器的 Node 安装方式相同。 .nvmrc开始涉及特定的环境管理问题，这大大增加了项目的范围。 我认为“环境管理”与“版本管理”是一个根本不同的问题。 我们已经在版本管理工作组中讨论了这些不同的用例。

虽然之前已经请求过此功能，但我没有足够的空闲时间来支持它。 由于需要通用环境管理解决方案（不仅仅是 .nvmrc）的人数众多，我正在尝试商业环境管理应用程序的想法，以简化这些流程。 支持社区的大型愿望清单所需的时间需要资金或赞助，所以我可能会依赖我已经为Fenix构建的基础设施。 问题：没有预计到达时间。

也就是说，请参阅路线图。 我提出的“免费”解决方案是一个钩子系统，类似于 git 的pre-commit 、 post-push等。这将允许开发人员创建自己的脚本以适应他们自己独特的环境。 想想像post-install 、 pre-use 、 pre-execute等操作。这将使用户能够编写一个钩子脚本来查找 .nvmrc 文件并即时切换版本.

@coreybutler所以基本上有两种不同的方法来安装多个版本的节点，对吗？

有点。 有两种不同的理念，但它们更多地是关于_使用_节点而不是安装它。

理念 1：原生使用（直接加工）
Node 本身不支持.nvmrc 。 它只是安装自己的可执行文件和 npm。 它是通过直接运行 node.exe _used_ 的。

理念 2：增强使用（子流程）
.nvmrc是原 nvm 项目引入的约定。 它没有直接调用 node.exe，而是使用了 shim。 垫片负责在将命令传递给节点可执行文件之前配置伪环境（即节点是垫片的子进程）。 这是处理.nvmrc逻辑的地方。 问题在于，尤其是在 Windows 上，节点在 shim 的上下文中运行，而不是在用户的上下文中运行。 这有许多影响/挑战，例如并不总是将适当的凭据传递给节点子进程（主要围绕提升的权限），环境变量略有不同，并不总是识别硬盘分区（如 D:\ 驱动器），以及（在在某些情况下）错误的文件路径（即__dirname行为异常）等。这些问题可以解决，但在考虑企业环境（Active Directory 部署、受限桌面、SAN 驱动器等）时，这些问题是复杂的。

一般的版本管理需要一定程度的填充，以防止每次需要切换版本（这将花费很长时间）时实际卸载/重新安装节点。 NVM4W 与第一种方法保持一致，使用符号链接来填充安装 _directory_，而不是选项 2，后者对可执行文件进行填充。 因此，您总是直接运行 node.exe 可执行文件，而不是将其作为子进程运行。

这个问题的小问题。 刚碰到它。

真的没有那么难。 如果未向nvm use提供版本，请执行以下操作：

1. 从 .nvmrc 获取版本
2. 安装了这个版本吗？ 如果没有 -> 安装它
3. 这个版本目前在使用吗？ 如果没有 -> 使用它。
4. 完毕

换句话说，如果没有指定版本号， nvm use是nvm install < .nvmrc和nvm use < .nvmrc （伪命令 - 现在实际上不起作用）。

没有更多了。

这个问题的小问题。 刚碰到它。

真的没有那么难。 如果未向nvm use提供版本，请执行以下操作：

1. Take version from .nvmrc

2. Is this version installed? If not -> install it

3. Is this version currently in use? If not -> use it.

4. Done

换句话说，如果没有指定版本号， nvm use是nvm install < .nvmrc和nvm use < .nvmrc （伪命令 - 现在实际上不起作用）。

没有更多了。

我很高兴我不是唯一一个遇到这个问题的人......
考虑切换回 linux 进行开发：/

@thany @jeromemeichelbeck随意 fork 项目并自己添加此功能。 准备好后，我会在此处发布链接。