node npm windows 文件路径太长无法安装包答案

【问题标题】：Node npm windows file paths are too long to install packagesnode npm windows 文件路径太长无法安装包
【发布时间】：2014-11-27 02:33:16
【问题描述】：

情况

我想在 Windows 托管的开发环境中使用 gulp 和相关的前端工具链。我在尝试使用像 Browser-Sync 这样的 gulp 插件时碰壁了，因为 node_modules 文件夹图扇出使 Windows 文件路径太长而无法复制文件。我想要一种实用的方法来立即在 Windows 上处理此问题，无论 Node 社区将来可能会或可能不会提供什么来提高 Windows 上的 npm 可用性。

2 个问题

是否有适用于 Windows 的 npm 工作流按预期方式工作？ “运行命令并安装文件”（例如，与 OSX 上的 npm、Linux 上的 npm、ruby gems 甚至 nuget 相当）我不想每次使用时都摆弄一堆手动文件编辑、符号链接等Windows 上的 npm。
是否有用于 npm 和节点执行的详细记录、稳定的 Cygwin 工作流来解决 Windows API 文件路径限制？

下面列出的血腥细节......

一般问题

在深度嵌套的 node_modules 层次结构中，从标准 Windows 命令提示符运行 npm install 失败。
Per Joyent 的 github 存储库线程 this is an acknowledged issue 在以 Windows 为中心的环境中没有适合开发人员的解决方法。（真的吗？）
NT 内核支持最长 32,767 个字符的文件路径长度。
Windows API 的 MAXPATH 限制为 260 个字符。
Windows API 处理所有主要 Windows shell 的文件操作，不包括：Explorer、CMD、Powershell、MYSgit bash 等（真的是 MS？NTFS 已经存在多久了？）
Cygwin 支持长文件路径，但由于 crlf 格式，npm.cmd 不能开箱即用。我在 npm 上尝试了 DOS2Unix 转换以使其与 Cygwin 一起使用，但似乎还有其他问题。

我目前的黑客攻击

在 C:\ 的根目录上创建一个“n”文件夹作为暂存区，因为这缩短了我的文件夹路径。
在“n”文件夹中运行 npm 来安装我需要的模块。
启动 Cygwin 并使用 cp 将 node_modules 文件夹复制到目标项目中。
当依赖项发生变化或我需要启动新项目时，冲洗并重复。

其他令人不快的解决方法

符号链接可用于缩短文件路径，但这些都是笨拙的技巧。随着 npm 生态系统的发展，嵌套的依赖链会变得太长，这种变通方法变得无法使用。

在我遇到的一个线程中提到了将所有依赖项添加到根文件夹的 package.json 文件中。尽管这种方法会使文件夹结构变平并防止加载重复的模块，但这种解决方法感觉不自然。它还扼杀了 npm 的可用性、耐用性和生产力，因为您必须在安装后手动或使用一些 hacky 脚本来摆弄文件和文件夹。该方法也容易受到符号链接方法最终可能遭受的相同命运的影响。

【问题讨论】：

我几乎以为我已经解决了这个问题。我通过在以下 2 个文件上运行 dos2unix util 让 Cygwin 与 npm 一起工作：npm.cmd 和 npm
Windows API 路径限制使 npm 无法使用，因为某些 npm 模块使用 Visual Studio 来构建文件。这是我在 npm Browser-Sync 时收到的错误：C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppBuild.targets(301,5): error MS B3491: could不要将行写入文件“Release\obj\validation\validation.tlog\validation.lastbuilds tate”。指定的路径、文件名或两者都太长。完全限定文件名必须少于 260 个字符，目录名必须少于 248 个字符。
我可能有一种“taffy-pulling”方法来让节点模块在 windows 上加载 npm。它涉及以下几轮：npm install、npm dedupe、npm shrink 和 rm -r node_modules。反复这样做似乎在某种程度上消除了长文件路径，但这有点像拉太妃糖（例如，直到你完成才完成）。有没有人对此进行了编码或编写了一个自动化工具来使其更加交钥匙？
说到“hacky 脚本”，我写了一个我不觉得非常 hacky 的脚本。我创建了一个名为fenestrate 的工具，您可以使用它在安装后以编程方式展平模块的目录结构。您可以将其安装为全局 npm postinstall hook。
@yoneal 供个人使用，为了快速上手，fenestrate 应该递归遍历你的 node_modules 文件夹，因此你不需要在深度依赖项上手动运行它。但是，分叉这些依赖关系会很棒——我认为许多具有简单 fenestrate 配置的分叉模块会向 npm 维护者发送一个很好的信息。

标签： windows node.js npm filepath

【解决方案1】：

Windows 8.1 和 10 可以选择增加 Win32 路径限制：

打开组策略编辑器（按 Windows+R 并输入 gpedit.msc 并按 Enter）
导航到以下目录：Local Computer Policy\Computer Configuration\Administrative Templates\System\Filesystem
双击启用 Win32 长路径选项并启用它。

【讨论】：

选项对我不可用，而且我从 win 7 pro 升级，所以这是一个可能的原因
@EvanMorrison "Filesystem\NTFS\Enable NTFS long paths" 在后来的 win10 版本中重命名为 "FileSystem\Enable Win32 long paths"。我更新了答案以供将来参考。
关于 Win Server 2012 R2 的任何想法

【解决方案2】：

如果您可以在全局范围内安装它，这可能是一种解决方法：

您可以将 npm 安装全局模块的路径调整为非常短的路径（通常是：c:\users\\{username}\AppData\Roaming\npm\npm_modules），这已经占用了很多字符。

要对其进行调整，请参见此处：Change default global installation directory for node.js modules in Windows?

如果您将其调整为，例如 c:\n\，在某些情况下它可能会解决问题。

【讨论】：

【解决方案3】：

npm install --no-bin-link。您将有一个整个扁平化 node_modules

【讨论】：

【解决方案4】：

在窗口中：

使用您的 Windows 资源管理器，导航到您的 vagrant 共享文件夹（顺便说一下，我使用的是 scotchbox）例如 C:\scotchbox/public/gulpProject
在文件夹的地址栏中，输入cmd，然后按Enter
进行 gulp 安装npm install

【讨论】：

Avoid copy-pasting the same answer。您应该改为标记为重复。此外，请勿在您的帖子中发誓。

【解决方案5】：

从 npm 版本 3.x 开始，Windows 上深度嵌套文件夹的问题已基本解决。

根据 npm：

.npm@3 通过将所有可能的东西提升到顶级 node_modules 来使安装“最大程度地平坦”。这意味着嵌套只发生在冲突中，因此，树永远不应该变得很深。因此，不应遇到 windows 路径长度限制。

我刚刚安装了 npm 3.1.0 并在一个抛出可怕的 The specified path, file name, or both are too long 错误的包上进行了尝试。

问题消失了。

您可以从这里获取最新的 npm 构建：npm releases

【讨论】：

我在 Windows 机器上的 npm 3.x 更新也取得了成功。无耻插件：我写了一篇关于Windows上npm 3的文章triplet.fi/blog/…

【解决方案6】：

我也有同样的问题。扁平化依赖关系并不是一个完整的解决方案，因为您可能正在使用依赖于同一依赖模块的不同版本的模块。我发现 gulp-run 模块在扁平化后停止工作（我怀疑与关于 bin/.bin 目录的模块假设有关）。呸！

有很多关于这个问题的讨论，但看不到解决方案： https://github.com/joyent/node/issues/6960

https://github.com/npm/npm/issues/3697

对我有用的解决方法是手动添加我的项目并不明确需要的依赖项。

如果您想确定哪些软件包给您带来了问题，我发现PathLengthChecker 非常有用。只需提取 EXE 并运行 GUI 或命令行应用程序。我发现问题的另一种方法是尝试在 Visual Studio 中构建，但它没有告诉你哪个目录名称太长就失败了。

这是我的解决方法的命令行示例：

mkdir c:\reallylongdirectorywillbreakinwindows
cd c:\reallylongdirectorywillbreakinwindows
npm init
npm install --save-dev grunt-bower-task
PathLengthChecker.exe RootDirectory="C:\reallylongdirectorywillbreakinwindows" MinLength=260

我回来了：

261: C:\reallylongdirectorywillbreakinwindows\node_modules\grunt-bower-task\node_modules\bower\node_modules\update-notifier\node_modules\latest-version\node_modules\package-json\no de_modules\registry-url\node_modules\npmconf\node_modules\config-chain\readme.markdown

[snip - 其中有 12 个]

根据npm ls命令：

└─┬ grunt-bower-task@0.4.0
  ├── async@0.1.22
  ├─┬ bower@1.3.12
  │ ├─┬ update-notifier@0.2.0
  │ │ ├─┬ latest-version@0.2.0
  │ │ │ └─┬ package-json@0.2.0
  │ │ │   └─┬ registry-url@0.1.1
  │ │ │     └─┬ npmconf@2.1.1
  │ │ │       ├─┬ once@1.3.1
  │ │ │       │ └── wrappy@1.0.1

让我们使用 npmconf - 它是所有导致问题的超长文件的容器。我们需要 npmconf 2.1.1。

npm install --save-dev npmconf@2.1.1
(now delete the node_modules directory - you may have to use Windows Explorer if you can't do it with rmdir /s)
npm install
PathLengthChecker.exe RootDirectory="C:\reallylongdirectorywillbreakinwindows" MinLength=260

没有结果 - 所有文件都在限制范围内！

这里明显的警告是每个包只能工作一次 - 不能在根 node_modules 级别安装对同一模块的不同版本的依赖项，因为节点不考虑目录结构中的版本。

此解决方法并不完美，但它解决了我在 Windows 上运行节点的主要目标，并且由于解决方案在 package.json 中是正确的，因此该解决方法适用于其他开发人员并构建服务器，无需任何手动或全局大惊小怪。

【讨论】：

【解决方案7】：

这就是最终为我解决的问题......

安装gulp并收到错误后，运行... gulp

当您看到某个包失败时，请使用 --no-bin-link 手动安装它。

sudo npm install {package} --no-bin-link

其中 {package} 是有问题的包。

在所有这些之后，我在插件“gulp-notify”中收到错误消息：未找到：通知发送。

这是由于 Vagrant 的插件问题。您可以关闭通知..

export DISABLE_NOTIFIER=true;

或者使用Vagrant安装插件。

祝你好运。我在这方面花了很长时间，即使在遵循了很多人的建议之后。

布兰登

【讨论】：

【解决方案8】：

艾伦-

从您链接的 github 问题中，

默认情况下，npm 将添加 dedupe-at-install-time。这比 Node 的模块系统更改要可行得多，但它仍然不是微不足道的，并且涉及对一些根深蒂固的模式进行大量返工。

这是（最终）目前在 npm 的作品，名称为 multi-stage-install，目标为 npm@3。 npm 开发负责人 Forrest Norvell 将在新的一年花一些时间在 Windows 上运行，所以请务必在 npm 问题跟踪器上创建与 Windows 相关的问题 https://github.com/npm/npm/issues >

【讨论】：

【解决方案9】：

这是一个变通解决方案。

有一些节点模块可以为您扁平化您的依赖关系。
链接在这里：

这些模块的工作也可以手动完成。这是目前唯一真正存在的解决方案，即将所有模块放在一个级别上，相互要求，而不是所有模块都将其依赖项的私有副本深度嵌套。

【讨论】：

我发现 flatten-packages 文档齐全且易于使用。