Node.js 项目依赖的过度递归答案

【问题标题】：Excessive Recursion of Node.js Project DependenciesNode.js 项目依赖的过度递归
【发布时间】：2014-04-03 23:52:16
【问题描述】：

所以在工作了一整天后，我坐下来，在系统托盘中看到 Windows SkyDrive 的警报：

Files can't be uploaded because the path of this file or folder is too long. Move the item to a different location or shorten its name.

C:\Users\Matthew\SkyDrive\Documents\Projects\Programming\angular-app\server\node_modules\grunt-contrib-nodeunit\node_modules\nodeunit\node_modules\tap\node_modules\runforcover\node_modules\bunker\node_modules\burrito\node_modules\traverse\example\stringify.js

...有一阵子，我对这种技术限制感到好笑。

然后，我想知道：Node 项目中的目录递归量真的有必要吗？看起来"angular-app\server\node_modules" 之外的路径只是整个项目的依赖关系，可能更好地表示为：

C:\Users\Matthew\SkyDrive\Documents\Projects\Programming\angular-app\server\node_modules\grunt-contrib-nodeunit\
C:\Users\Matthew\SkyDrive\Documents\Projects\Programming\angular-app\server\node_modules\nodeunit\
C:\Users\Matthew\SkyDrive\Documents\Projects\Programming\angular-app\server\node_modules\tap\
C:\Users\Matthew\SkyDrive\Documents\Projects\Programming\angular-app\server\node_modules\runforcover\
C:\Users\Matthew\SkyDrive\Documents\Projects\Programming\angular-app\server\node_modules\bunker\
C:\Users\Matthew\SkyDrive\Documents\Projects\Programming\angular-app\server\node_modules\burrito\
C:\Users\Matthew\SkyDrive\Documents\Projects\Programming\angular-app\server\node_modules\traverse\

我之前并没有真正考虑过，因为与许多平台相比，Node 中的包管理似乎很神奇。

我想一些大型的 Node.js 项目甚至包含许多重复的模块（具有相同或相似的版本），这些模块可以合并成更少的数量。可以这样说：

由于以下原因而存储和传输的数据量增加重复的依赖增加了开发软件的成本。
较浅的目录结构（尤其是在这种情况下）是通常更容易导航和理解。
过长的路径名可能会导致某些计算出现问题环境。

我提出的（如果不存在这样的东西）是一个 Node 模块：

递归扫描 Node 项目，收集嵌套的 node_modules 文件夹列表以及它们相对于项目根目录的埋藏深度。
将每个嵌套的 node_modules 文件夹的内容移动到主 node_modules 文件夹，编辑每个 .js 文件的 require() 调用，这样就不会破坏任何引用。
处理多个版本的重复依赖项

如果不出意外，这将是一个有趣的实验。你们有什么感想？我可能会遇到哪些潜在问题？

【问题讨论】：

标签： javascript node.js recursion npm onedrive

【解决方案1】：

看看

npm dedupe

让你正确。

API文档here

【讨论】：

我在this project 的服务器目录中运行了该命令，并且仍然能够导航到上面那个很长的C:\...\example\ 路径。 Here 是控制台输出（一些冲突）。
不幸。值得一试。你可以在this SO question 上找到一些其他的想法，我觉得我不久前看到了另一个关于这个主题的想法。如果我再次找到它会发布。
谢谢你的回答（我不知道npm dedupe）和那个链接。听起来@blesh 的想法与我上面的建议相似。
不客气，尽管令人失望的是它无法解决您的问题。 FWIW，我认为模块作者在正确指定依赖项方面的更好实践会有所帮助。好的，坏的只有“1.2.3”语法，这很烦人，有时对库的自反依赖也是如此，例如安装下划线只是为了使用_.extend()。

【解决方案2】：

请参阅fenestrate、npm-flatten、flatten-packages、npm dedupe 和 multi-stage-installs。

引用 this StackOverflow question 的 Sam Mikes 的话：

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

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

【讨论】：