节点npm windows文件路径太长，无法安装包

Question

我想在Windows托管的开发环境中使用gulp和相关的前端工具链。我在尝试使用gulp插件（如Browser-Sync）时遇到了困难，因为node_modules文件夹图扇形，使得windows文件路径太长，无法复制文件。我想要一个务实的方法来处理这个问题，现在就在Windows上，不管节点社区可能会或可能不会提供什么来提高npm在Windows上的可用性。

2个问题

>

是否有Windows的npm工作流按预期方式工作？“运行命令并安装文件”（例如，与OSX上的npm、Linux、ruby gems甚至nuget上的npm)相比，我不想每次在Windows上使用npm时都要进行大量的手动文件编辑、符号链接等。

下面列出了血淋淋的细节...

一般问题

• 在深度嵌套的node_modules层次结构上，从标准Windows命令提示符运行npm安装失败。
• 根据Joyent的github repo线程，这是一个公认的问题，对于以Windows为中心的环境中的开发人员来说，没有令人满意的解决办法。（真的吗？）
• NT内核支持最多32,767个字符的文件路径长度。
• Windows API的MAXPATH限制为260个字符。
• Windows API处理所有主要Windows shell的文件操作，包括:Explorer、CMD、Powershell、MYSgit bash等（真的吗？NTFS存在多久了？）
• Cygwin支持长文件路径，但是由于crlf格式的原因，npm.cmd不能开箱即用。我尝试了npm上的DOS2Unix转换，以使其与Cygwin一起工作，但似乎还有其他问题。

null

符号链接可以用来缩短文件路径，但这些都是很难的黑客攻击。随着npm生态系统的增长，嵌套依赖链将变得太长，这种变通方法将变得不可用。

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

Answer 1

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

根据国家预防机制：

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