我想立即预订：本文未提供可供使用的食谱。 这是我到Typescript和NodeJS的世界旅行的故事，以及我的实验结果。 不过，在本文的结尾，将有一个指向GitLab存储库的链接，您可以看到它，也可以自己取一些喜欢的东西。 也许即使以我的经验，也可以创建自己的自动化解决方案。
为什么有必要
那么，为什么您需要根本创建库，或者在特定情况下需要创建NPM包？
- 在项目之间重用代码。
这一切都始于我注意到在项目中创建文件夹/工具的习惯。 另外，当我切换到新项目时，我也随身携带了该文件夹的大部分内容。 然后我问自己一个问题，为什么不制作NPM软件包而不是复制粘贴，然后将其连接到任何项目？ - 不同的生命周期。 在其中一个应用程序中，有大量的公司组件组装成依赖关系。 即使仅更新了一个组件，也可能仅对其进行整体更新。 其他组件的更改可能会破坏某些内容，并且我们并非总是有足够的估计时间来对其进行重新测试。 这种模式非常不方便。 当每个程序包达到其目的或一小组相关目标时，就可以在确实需要时对其进行更新。 此外，该软件包的以下版本仅在进行某些更改时才发布，而不是“针对公司”。
- 将次要代码与核心业务逻辑分开。 DDD具有域提纯的原理；它涉及识别不属于主域的代码段并将其与它们隔离。 与将这些代码带入一个单独的项目相比，隔离起来更好。
顺便说一下，域蒸馏仅在不同级别上与SRP原理非常相似。 - 自己的代码覆盖率。 在我参与的一个项目中，代码覆盖率约为30％。 我从中取出的图书馆覆盖率约为100％。 该项目虽然失去了覆盖率，但由于在拆除前位于红色区域，所以仍然存在。 在将近一年的时间和四个主要版本的支持下，该库至今仍具有如此令人羡慕的指标。
- 开源的 不包含业务逻辑的代码是与项目分离的第一个候选对象，因此可以使其公开。
推出“昂贵”的新图书馆
有一个问题：为了创建一个库，仅在下面获得一个git仓库是不够的。 您还需要配置任务，以便可以组装项目，进行静态验证（皮棉）和测试。 另外，除了测试之外，建议收集代码覆盖率。 此外，您每次都必须手动发布该程序包。 并且仍然需要编写自述文件。 只是自述文件我无法帮助。
那么，如何处理所有这些无聊而无趣的任务呢？
第一步：种子
我首先创建一个种子项目。 这是一种入门工具包，其结构与我第一个将代码放入单独的程序包中的项目相同。 我在其中创建了gulp任务和脚本，这些任务和脚本可以一次生成，测试和收集程序包覆盖率。 现在，要创建另一个项目，我需要将种子克隆到一个新文件夹中并更改原点，以便它指向GitHub上新创建的存储库（然后我仍使用GitHub）。
这种创建项目的方式提供了另一个优势。 现在，在种子项目中对项目的构建或测试进行一次更改。 并且不再需要复制粘贴这些更改。 取而代之的是，在最后一个项目中，下次我必须使用它时，我创建另一个名为“种子”的遥控器，然后从那里进行这些更改。
它对我有用了一段时间。 直到我在多个开发人员参与的项目中使用种子。 我分三步编写了说明：掌握最后一个母版，构建并发布。 在某个时候，一个开发人员出于某种原因完成了第一步和第三步。 这怎么可能？
第二步：自动发布
尽管这是一个单一的错误，但诸如发布之类的手动操作却很无聊。 因此，我认为有必要使其自动化。 此外，还需要CI来防止红色提交进入主机。 最初，我尝试使用Travis CI，但遇到了以下限制。 他认为master中的pull-request等同于master中的commit。 我不得不做不同的事情。
我的一位同事建议我注意GitLab及其CI，以及我想要的所有东西。
我创建了以下处理项目的过程，该过程在您需要修复错误，添加新功能或创建新版本时使用：
- 我从主人创建一个分支。 我在其中编写代码并进行测试。
- 我创建一个合并请求。
- GitLab CI自动在节点中运行测试：最新容器
- 该请求通过了代码审查。
- 冻结请求后，GitLab将运行第二组脚本。 该集合在提交上使用版本号创建标签。 版本号取自package.json，如果在此处手动增加，则不取，则采用最新发布的版本并自动递增。
- 该脚本将构建项目并再次运行测试。
- 在最后的步骤中，将版本标记发送到存储库，并将程序包发布到NPM。
因此，标记中指示的版本始终与此提交发布的软件包的版本匹配。 为了使这些操作生效，您需要在GitLab项目中使用对存储库和NPM的访问键来指定环境变量。
最后一步：自动化一切
在这一点上，我已经实现了很多自动化，但是仍然有很多手动操作来创建项目。 无论如何，这当然已经取得了进展，因为每个项目都执行了一次操作，而不是每个版本都执行了一次。 但是，该指令仍包含11个步骤。 我本人由于采取了这些步骤而被误解了两次。 然后我决定，自从开始自动化以来，我需要结束这一点。
为了实现这种完全自动化，但是在计算机中，我需要在.ssh文件夹中包含3个文件。 我认为该文件夹受到了很好的保护，因为id_rsa私钥已经存储在该文件夹中。 该文件还将用于使GitLab CI能够将标签传递到存储库。
我放入的第二个文件是“ gitlab”，它包含对GitLab API的访问密钥。 第三个文件是“ npm”，这是发布程序包的访问密钥。
然后魔术开始了。 创建新软件包所需要做的就是在种子文件夹中运行一个命令：“ gulp startNewLib -n [npmName] / [libName]”。 完成后，程序包即已创建，可以进行开发和自动发布。
例如，以这种方式创建了软件包“ vlr / validity”。
该命令执行以下操作：
- 在GitLab上创建一个项目
- 克隆种子到运行命令的文件夹旁边的本地文件夹。
- 将源更改为在步骤1中创建的项目
- 推送主分支
- 通过.ssh文件夹中的文件在项目中创建环境变量
- 创建一个firstImplementation分支
- 更改package.json中库的名称，提交并推送分支
完成此操作后，您所需要做的就是将代码放在此处并创建合并请求。
因此，从决定将某种代码放入单独的项目到发布第一个版本的那一刻之间，大约需要五分钟的时间，这可以引以为傲。 其中四个占用两个GitLabCI管道，一分钟启动上述命令，拖放代码，然后单击GitLab界面中的按钮创建并保存请求。
有一些限制：GitLab名称必须与npm中的名称匹配。 但是，与种子项目中的其他功能不同，此命令仅在Windows上有效。
如果您对该种子项目感兴趣，可以
在以下链接中进行研究 。