ngnewapp生成的Angular应用，自带11个依赖：使用Schematics安装库后的CustomerStorefront：在本地新建一个空文件夹，在里面执行命令行：npmi@spartacus/storefront下只有一个node_modules文件夹，里面有很多js文件和TypeScript.d.ts文件：@Spartacus/storefront的package.json中，依然只有一个tslib依赖：但是peerDependencies包含不同的Spartacus项目源码package.json中定义的lessdependencies:"peerDependencies":{"@angular/common":"^12.0.5","@angular/core":"^12.0.5","@angular/形式”：“^12.0.5”，“@angular/platform-b??rowser”：“^12.0.5”，“@angular/router”：“^12.0.5”，“@angular/service-worker”：“^12.0.5","@ng-bootstrap/ng-bootstrap":"^10.0.0","@ng-select/ng-select":"^7.0.1","@ngrx/effects":"^12.1.0","@ngrx/router-store":"^12.1.0","@ngrx/store":"^12.1.0","@spartacus/core":"4.3.1","ngx-infinite-scroll":"^8.0.0","rxjs":"^6.6.0"}，npm很好地处理子依赖关系：如果我的包依赖于请求版本2和其他一些库，但其他库依赖于请求版本1，则生成的依赖关系图如下所示：这通常很棒：现在一些-other-library有它自己的请求的v1副本，它可以在不干扰我的包的v2副本的情况下使用它。但是，有一个用例失败了：插件。插件包旨在与另一个主机包一起使用，即使它并不总是直接使用主机包。在Node.js包生态系统中已经有很多这种模式的例子：但更重要的是，它们旨在与特定版本的托管包一起使用。例如，我的chai-as-promised插件的1.x和2.x版本适用于chai0.5版本，而3.x版本适用于chai1.x。另一个例子是咕噜声。grunt-contrib-stylus的0.3.1版可与grunt0.4.0rc4一起使用，但由于API删除而在与grunt0.4.0rc5一起使用时会中断。假设插件显式声明了宿主包的版本号，即使对于确实有这种直接依赖的插件，也许由于宿主包提供了一个实用的API，在插件的package.json中指定依赖会导致依赖树包含主机包的多个副本。例如，假设winston-mail0.2.3在其依赖项中指定winston:0.5.x，因为这是对其进行测试的最新版本。作为应用程序开发人员，我使用最新版本的winston0.6并将它们放在package.json中：一旦运行npminstall，就会生成两个不同版本的winston：解决这个问题的方法是使用peerDependencies.peerDependencies非常简单。编写plugin时，请确定peerDependencies的host包版本，并在package.json中添加：{"name":"chai-as-promised","peerDependencies":{"chai":"1.x"}}现在，当安装chai-as-promised时，chai包将随之安装。如果您稍后尝试安装另一个仅适用于0.x版Chai的Chai插件，您将收到一条错误消息。
