当项目变得不止一个时，就需要以某种方式不仅复用带有代码的单个模块，而且还要复用UI组件本身。 解决问题的方法有很多，从传统的复制粘贴到设置带有测试，文档甚至二十一点的单独项目。
问题在于，第二个选项需要大量的准备工作，并且每个这样的项目都是唯一的-具有其自己的工具，每个新开发人员都需要使用它来再次处理它。 在7月底，Angular团队针对此问题提出了自己的综合解决方案，方法是在angular / cli中添加创建库的新命令-库。
让我们看看结果如何。
为了进行测试，采用了angular / cli的最新稳定版本-6.1.5（09/04/2018）
完美世界
在理想的世界中，一切都应该方便。 因此，对于组件库，我将重点介绍三个要点
因此，让我们从头开始。
为了创建我们自己的库，我们需要采取两个步骤-创建一个新项目并向其中添加一个库。 首先，创建一个新项目：
npx @angular/cli@latest new mylibapp
像素我使用npx不能全局安装cli并避免npm run构造。 如果您具有npm 5.2或更高版本，请尝试一下。 在这里阅读更多
执行完命令后，我们将看到一个标准项目（6角，与第5版不同），其中将创建两个子项目-主mylibapp和mylibapp-e2e。 现在在angular.json中描述了角度项目本身。
还没有图书馆。
这是他的第一个警告。 我们的名称已经由主项目使用，并且命名库也将不起作用。 因此，如果要将该库命名为my-super-library，则首先需要创建一个项目，该项目的名称应有所不同。 例如，我的超级图书馆项目。 只有这样，才能使用所需名称创建一个库。
现在创建第三个子项目并生成一个库。
cd mylibapp npx ng generate library mylib
不必指定前缀，但是非常希望不要与其他库相交。
如您所见，现在，我们的第三个库已添加为第三个子项目。 它具有自己的独立package.json，tsconfig和karma.conf.js，可让您对其进行配置，而不必担心会损害其他项目。 顺便说一句，如果需要，我们可以添加另一个库，它也将是一个单独的子项目。 但这就是为什么我不知道该库不能被一个完全独立的项目（例如在.Net中）区分的原因。 而且，如果手动移除e2e项目并不困难，那么主项目将不再存在。 结果，额外的代码出现在存储库中，这不是很好。
现在，让我们看看我们可以立即使用哪些工具。 这是一堆tslint + codelyzer，业力+茉莉花和e2e量角器。 即 标准的角度项目集，没有针对我们未带到的图书馆的任何内容。 这有点奇怪，因为必须有一些用于查看组件并将其呈现到文档中的工具（例如Storybook ）。 但是好吧，我们将假定他们在这里只是为我们留出了回旋余地。
让我们运行测试和lint，以确保一切正常。
npm test mylib npx ng lint mylib
一切对我来说都很好，但是Chrome用于测试，这也很奇怪。 我没有反对他的想法，但是在构建服务器上不会是90％。 他们为什么不使用同一人偶呢？
总结一下：
优点
缺点
到目前为止，没有任何关键问题，我们将继续深入研究。
发展历程
我们已经有一些现成的组件，让我们看看它们。 由于我们没有任何特殊工具，因此我们将使用主项目（此处说明了为什么需要它）。 为此，我们需要构建库，导入库模块并启动主项目。
一些代码 npx ng build mylib
import { MylibModule } from "mylib"; ... @NgModule({ declarations: [ AppComponent, ], imports: [ BrowserModule, MylibModule ], providers: [], bootstrap: [AppComponent] })
npm start
完成所有操作后，我们将从库中看到我们的组件。 但还是有一个细微差别-库的监视模式尚未完成，您是否需要每次运行自己构建的库？ 手表只会出现在Angular / CLI 6.2+中。 并非开箱即用，为此，您必须在tsconfig.json中添加一个新标志
tsconfig.json
"angularCompilerOptions": { "enableResourceInlining": true, }
然后使用watch标志运行构建：
ng build mylib
如果出于某些原因在6.2下使用cli，则必须自己构建它，坦率地说，这是不好的。
现在让我们添加一个新组件。 为此，请运行标准的generate component命令。 由于该库不是我们的主要项目，因此您必须使用项目标志，这也有点烦人（但如果该库是一个独立的解决方案...）。
npx ng generate component some-nice-image
现在，在mylib / src下，创建资产文件夹，添加图片并再次重建库以查看结果。 然后另一个惊喜等待着我们-没有图片。 事实证明，库中使用的资源不会自动进入构建，您需要自己复制它们（或那样 ）。 它似乎并不可怕，但仍然不正确。
但是摇树应该开箱即用。 让我们在库中创建另一个组件，但是我们不会在主项目中使用它。 以生产模式整合主要项目
npx build
而且我们看到捆绑包的大小没有改变。 摇树确实适用于库！
现在，尝试上瘾会很好。 由于每个项目都有其自己的package.json，因此我们首先需要转到库文件夹并执行npm install命令
npm i -D @drag13/when-do npm i @drag13/round-to
我故意以不同的方式将它们放在包装机上，以检查包装机以后如何处理。 一切设置都没有问题。 我们试图收集并得到警告
不建议使用“依赖项”分发npm软件包。 请考虑将drag13 / round-to添加到“ peerDependencies”或从“依赖项中删除”
分发npm依赖程序包是不可取的。 请考虑将drag13 / round-to依赖项添加到peerDependencies甚至从依赖项中将其删除
然后是错误：
依赖项drag13 /舍入必须明确列入白名单
必须将drag13 /舍入相关性明确添加到白名单中。
通过设计，这已经很有趣了，该库不希望具有直接依赖关系。 我们正在尝试将沉迷于peerDependencies部分并进行重组-瞧，一切正常。 但这意味着第三方库的安装顺序现在有所不同。 首先，将依赖项放在主模块上，然后使用笔将笔添加到库的peerDependencies部分。
其余的工作与常规Angular项目中的工作相同。
简要总结一下：
优点：
缺点：
- 要“查看组件”，您需要使用整个项目
- 尚无观看模式
- 需要手动复制资源或自行配置构建过程。
最后，转到出版物
过帐
一切都在这里。 Angular / cli使用完善的ng-packgr进行发布，它将独立地将我们的代码编译成适合npm发布的程序包，而忽略 package.json文件设置（这不小），缩小，以不同格式打包（例如，以UMD打包） 。
为了发布您的软件包（或查看其中的内容），您需要运行三个命令
npx ng build
如果您不想发布，请用pack替换publish命令
结果，我得到以下信息：
首先，让我们看一下package.json，它看起来与我们库的原始package.json完全不同。
如您所见，packagr并未删除我们的devDependencies，尽管有些删除了。 另外，从理论上讲，对于package.json中描述的格式数量感到满意（即使我不知道其中的一半）。
包装内包含一个UMD格式的缩小和非缩小的包，以及多个内部角度格式的包（fesm5，fesm2015）。 但是，最重要的是，现在开发人员的头脑不会为此感到伤害，这真是太好了。
让我们继续得出结论。
优点：
合计
解决方案很有趣，但还很原始。 开始和发布非常方便，但是仍然有待开发的问题。 特别令人沮丧的是，该库现在不是设计上独立的项目，而是对主要项目的补充，有可能出版。
另一方面，已经完成了大量工作，功能不断发展，并且我相信随着时间的推移，我们将获得出色的开发工具。