Nvm-windows: 安装文件夹不正确

创建于 2016-04-05  ·  12评论  ·  资料来源: coreybutler/nvm-windows

我的环境

  • [ ] 视窗 10

AppData 文件夹用于数据,而不是可执行文件。 这不应该默认安装在那里,更不用说漫游分支了,它会自动复制到同一 Windows 域上的每台机器上。

Installer Issue

最有用的评论

以下是基线建议:

  • 程序进入%ProgramFiles% ,通常是C:\Program Files
  • 在 64 位机器上,旧的 x86 程序进入%ProgramFiles(x86)% ,通常是C:\Program Files (x86)
  • 机器范围的程序数据,如包缓存,进入%ProgramData% ,通常是C:\ProgramData
  • 可以安全地从机器漫游到机器的用户设置进入%APPDATA%
  • 给定机器本地的用户设置(例如包含安装路径的设置)放在%LOCALAPPDATA%

所有12条评论

是我弄错了,还是 NVM 只是将 400MB 的节点包缓存放入了我的漫游配置文件中?

不,这是 NPM 中的错误。

默认安装指向本地用户appdata目录,而不是漫游目录。 虽然将可执行文件放在不同的位置可能更好,但所有节点安装文件和 npm 都被视为 NVM 的数据(这是一个 npm 设计)。 同样,出于某种原因,这些是默认值……如果您不喜欢它们,可以更改它们。

我不知道你从哪里得到 400MB。 您能否提供有关您的环境的更多详细信息?

在第一点上,也许不同之处在于我将它安装在连接域的计算机上,而您不是。 但无论哪种方式,它仍然是错误的。 AppData 用于用户设置,而不是可执行文件。

至于第二点,是 Node 本身犯了这个错误。 我将分别向他们提交错误。

这不一定是“错误”,但如果它产生不利影响,我很乐意考虑您的用例。 我对连接域的计算机没有相同的经验,因此,环境的详细信息将帮助我了解您的特定用例。

例如,如果我知道要查找什么,我可以使安装程序的下一个版本具有域感知能力。 换句话说,默认安装位置可能更智能。

以下是基线建议:

  • 程序进入%ProgramFiles% ,通常是C:\Program Files
  • 在 64 位机器上,旧的 x86 程序进入%ProgramFiles(x86)% ,通常是C:\Program Files (x86)
  • 机器范围的程序数据,如包缓存,进入%ProgramData% ,通常是C:\ProgramData
  • 可以安全地从机器漫游到机器的用户设置进入%APPDATA%
  • 给定机器本地的用户设置(例如包含安装路径的设置)放在%LOCALAPPDATA%

可执行文件在 appdata 中的情况并不少见。 使用 clickonce 安装的应用程序可以做到,这是由微软制作的安装程序。 Chrome 做到了。 很多事情都是这样做的。

@aljones一个主要的原因就是这个-用户配置文件安装程序可以很方便,但它绝对有,由于它为所欲为任何进程都可以修改的东西安全后果。 请注意 ClickOnce _does_ 安装在用户配置文件中,但也确保程序集在系统上具有较少的权限。

虽然在不需要管理权限的情况下为每个用户安装应用程序的一般用例,但这是一个非常糟糕的默认行为,Chrome 在这里树立了一个不好的先例,恕我直言。

我相信我最近的经历与讨论有关:我最近有一台工作站交换机。 我的漫游配置文件中 node_packages 的路径如此之深,以至于我的机器尝试执行的漫游配置文件还原每次都会失败,直到我炸掉 node_packages 文件夹。 这些错误出现在 Windows 事件日志中。 在我这样做之后,我的新工作站终于可以同步我的漫游配置文件了。

我同意,当您在备份您的配置文件以在其网络中使用的公司工作时,安装到漫游会导致问题。 例如,我的电脑关机需要 30 分钟,重启需要 30 分钟; 这一切都归功于 npm 模块。 不幸的是,AFAIK,这是 NPM 本身的问题。

作为对此的跟进:

一般来说,重要的是要注意任何版本管理器都只是管理程序。 我重申以前的评论.... 在 NVM 的意义上,已安装的程序(节点)_is_ 数据。 您如何使用它(即 npm 模块)会影响占用空间。

@sam3k是正确的,足迹肯定与 npm 的设计方式有关,而且 NVM _should_ 对此确实没有多少,npm 本身也无能为力。 归结为知道您要安装什么,并且任何类型的包管理器都可以轻松地将其视为理所当然。 许多人不注意模块的足迹,这是开源世界固有的代码/环境质量问题。 归根结底,由社区通过严格的编码实践(一项远非微不足道的任务)来解决这个问题。 我是许多提倡这一点的人之一(请参阅npm 需要私人教练。要点:npm 管理超出了管理您正在运行的节点版本的基本前提。

@aljones@ygra都有优点。 我并不反对他们,但我确实想提醒大家,管理权限是使符号链接起作用的必要条件。 这是 NVM for Windows 工作原理的核心原则。

@cokobware有我认为在企业环境中常见的问题。 底线是 npm 的设计目的不是为了便于大规模移植。 一个node+npm的实例已经很重了,更别说添加多个版本了。 不管数据/文件如何从工作站移动到工作站,它们都太多了,需要一段时间。 选项是使用 Windows 漫游配置文件、压缩所有内容并手动传输,或从 npm 注册表重新下载。 无论您如何旋转,同步工作站都需要时间才能将所有位放入正确的位置。

Windows 版 NVM 的未来(截至目前)可能仍将专注于节点版本切换。 我什至可能会更改项目名称以反映这一点。 它将继续为安装程序提供通用默认值,但仍由组织/开发人员以适合其组织的方式覆盖这些默认值。 我认为节点版本管理是一个与 npm 足迹管理截然不同的问题,尽管我正在试验 NVM4W 可以提供挂钩以实现更好的 npm 管理的方法。

请遵循@Grauenwolf建议和这些参考资料:部署指南CSIDL环境变量

  • 将 %USERPROFILE%AppData 符号链接到 %PROGRAMFILES% 或 %PROGRAMFILES(X86)% 是个坏主意。 多用户问题(所有权问题。其他用户无法访问链接)。
  • 程序 nvm 假设存储在 %PROGRAMFILES% 或 %PROGRAMFILES(X86)% 中。
  • nodejses 存储库应该存储在 %PROGRAMDATA% 中,因为范围是所有用户。
  • 活动 nodejs 链接应该存储在 %LOCALAPPDATA% 中,因为范围是每个用户。

由于其他错误,NVM 无法安装在 %PROGRAMFILES% 中。 如果将其放在名称中包含空格的文件夹中,则安装命令将失败。

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

SufyanParkar picture SufyanParkar  ·  4评论

martijnsenden picture martijnsenden  ·  3评论

fredericrous picture fredericrous  ·  3评论

leiamac picture leiamac  ·  4评论

snerte picture snerte  ·  5评论