继续之前的例子。现在我们有一个应用依赖2个模块：
- Module-A,依赖模块B v1.0
-
Module-C,依赖模块B v2.0
例子：
现在我们想要依赖另一个包，module D.Module D依赖moduleB v2.0，就像Module C一样：
因为B v1.0已经是顶级依赖，我们依然不会将B v2.0作为顶级依赖。因此B v2.0作为嵌套依赖安装在Module D下面，技师我们已经有了一个一样的安装嵌套在模块C下。
如果二级依赖被2+模块需要，但是在目录的层级不是安装在顶级依赖，就会重复和嵌套在主要的目录下。
但是，如果二级目录被多个模块需要，但是作为顶级依赖安装的。就不会重复，并且通过顶级依赖共享需要。
比如，我们需要模块E，像模块A，依赖于模块B v1.0
因为B v1.0已经作为顶级依赖，所以就不会重复嵌套。可以简单的安装模块E并且和模块A共享模块B
在终端里展示如下：
那么现在，如果我们将模块A更新到v2.0，依赖与模块B v2.0,而不是B v.10会怎么样呢？
记住安装的顺序是很重要的。
即使在我们的package.json首先安装的时候模块A v1.0,使用npm install命令意味着模块A v2.0是后面安装的。
当我们运行npm install mod-a@2 --save时，npm3会做以下的事情：
- 删除ModuleA v1.0
- 安装ModuleA v2.0
- 会保留ModuleB v1.0 因为Module E仍然需要它
- 会将Module B v2.0作为ModuleA v2.0的嵌套依赖安装，因为ModuleB v1.0占了顶级目录层级
在终端里看是这样的：
最后，我们也将Module E更新到v2.0,同样依赖于Module B v2.0而不是Module B v1.0,就像module A更新一样：
npm3执行以下事情：
- 删除Module E v1.0
- 安装Module E v2.0
- 删除Module B v1.0，因为不再有依赖
- 将Module B作为顶级依赖安装，因为顶级没有Module B
在终端里如下：
现在，很明显不太好。我们几乎在每个目录都有模块B。为了去重，执行：
npm dedupe
这个命令会将所有的依赖Module B v2.0的引用指向顶级的Module B v2.0，然后删除掉嵌套的依赖。
终端如下：
