我有3个依赖项，都引用了esprima-fb，版本解析为15001.1001.0-dev-harmony-fb。
我希望在node_modules文件夹的顶层看到esprima-fb，但它并不存在。它们位于每个依赖项的node_modules文件夹中。
一切仍然有效，但这意味着我无法成功确保我的npm-shrinkwrap.json文件是最新的，因为我使用的工具希望在npm-shrinkwrap.json的顶层找到esprima-fb依赖关系，而不是嵌套在每个依赖关系中。
我的问题是，哪一位表现得出乎意料？ npm没有安装至少1个版本的esprima-fb到顶级？比较工具假设npm将始终以这种方式运行？
答案 0 :(得分：2)
我遇到esprima-fb嵌套在jstransform下的相同行为。我不知道嵌套esprima-fb的原因，但我发现node-pre-gyp嵌套在fsevents下，我认为这是因为node-pre-gyp是捆绑的依赖关系（请参阅{{ 1 {} package.json）。捆绑的依赖项与模块一起发布。如果您查看npm缓存中的gzip，您会发现在jstranform内的压缩包含在其父级内的捆绑式依赖项。我称他们为模块偷渡者。
答案 1 :(得分：0)
虽然效率很低，但npm并没有使依赖性变平（因为它的所有三个副本都在同一版本中，这很奇怪），这种行为完全有效。另一个工具不应该期望依赖安装在顶层。
如何看待它的另一种方式：如果这3个esprima-fb依赖关系解决了略有不同的版本会怎么样？在这种情况下，不平坦化这些依赖关系是唯一的选择。