大家好 最近，我遇到了设置私有npm软件包的任务。 一切听起来都非常有趣并且充满希望，直到事实证明那里没有太多事情要做。 一切都将在这里结束，但是第二个任务出现了-为npm包编写一个演示存储库，可以将其提取，克隆并基于它快速创建有用且相同的样式。
结果是一个具有自定义格式，代码样式，每个池的测试，代码覆盖率限制，代码覆盖率报告和自动文档的项目。 加上在npm中方便的发布。 有关设置的详细信息-剪切下。
要求条件
首先，我弄清楚我们已经拥有了什么：
- 新项目使用TypeScript编写
- 除了新项目，还有许多纯JavaScript项目
- 有编写测试的要求，并且必须将结果发送给分析
然后，他估计了自己的心愿单-既然有时间和渴望，为什么不那么轻松。 我想要更多：
- 我想要统一的格式样式
- 我想要统一的TypeScript样式
- 我需要文档，但我不想写它
- 总的来说，我想使一切自动化。 每年生产多少次？
结果，需求形成如下：
- 该模块必须是TypeScript并使用TsLint进行了测试
- 必须在TypeScript和JavaScript下使用该模块
- 测试应在git hook上配置，最小代码覆盖率也应配置，统计信息应为
- 必须配置格式
- 必须从代码创建文档。
- 发布应该方便且一致。
- 所有可以自动化的
看起来不错，您需要尝试。
初步手势
我们创建（克隆）存储库，初始化package.json，在本地设置TypeScript。 通常，我们在本地设置所有依赖项，因为 一切都会转到服务器。 不要忘记修复版本依赖性 。
git init npm init npm i -D typescript ./node_modules/.bin/tsc --init
立即就地需要您自己调整tsconfig.json-设置目标，库，包含/排除，outDir和其他选项。
为了保持统一的格式，我使用了两个工具。 第一个是.editorconfig文件。 所有主要的IDE（WebStorm，VSCode，Visual Studio等）都可以理解它，不需要安装任何多余的东西，并且可以处理大量文件类型-js，ts，md等。
#root = true [*] indent_style = space end_of_line = lf charset = utf-8 trim_trailing_whitespace = true insert_final_newline = true max_line_length = 100 indent_size = 4 [*.md] trim_trailing_whitespace = false
现在，自动格式化的行为与我的同事们差不多。
第二个工具更漂亮 。 这是一个npm软件包，它检查并在可能的情况下自动更正文本格式。 在本地安装并将第一个命令添加到package.json
npm i -D prettier
package.json
"prettier": "prettier --config .prettierrc.json --write src*.ts"
漂亮的人没有init命令，因此您需要手动配置它。 在项目的根目录中使用类似此有争议的内容的内容创建.prettierrc.json（如果有的话，该帖子根本不是关于哪个引号是更好的，但是您可以尝试）
.prettierrc.json
{ "tabWidth": 4, "useTabs": false, "semi": true, "singleQuote": true, "trailingComma": "es5", "arrowParens": "always" }
现在创建src文件夹，创建带有一些条件内容的index.ts并尝试运行更漂亮的文件夹。 如果他不喜欢您的格式，他会自动修复。 很舒服 如果您不想仅在提交/推送过程中记住此操作，则可以将其配置为自动运行或为Studio安装扩展程序。
代码风格
使用代码样式，一切也不复杂。 对于JavaScript，有eslint ；对于TypeScript，有tslint 。 我们放入tslint并创建tsconfig.js来存储设置
npm i -D tslint ./node_modules/.bin/tslint --init
package.json
"lint": "tslint -c tslint.json 'src/**/*.ts' 'tests/**/*.spec.ts'"
您可以编写自己的规则，也可以使用extend参数使用现有规则。 例如， 这里是airbnb的配置。
Tslint开发人员在开玩笑 module.exports = { extends: "./tslint-base.json", rules: { "no-excessive-commenting": [true, {maxComments: Math.random() * 10}] } };
那不是很漂亮吗？
有一点很重要-tslint和更漂亮的功能相交（例如，字符串的长度或“挂”逗号）。 因此，如果您同时使用两者，则将需要监视合规性或放弃某些操作。
但是，对于那些不想检查所有文件，而是仅检查上载的文件的用户，可以使用lint-staged软件包
测验
首先，我们需要什么测试？ 首先，使它们自动启动；其次，进行覆盖率控制；其次，最好以lcov格式提交某些报告（如果有的话，不同的分析仪（从SonarQube到CodeCov）都可以很好地理解lcov）。 我们将在稍后自行设置测试的同时处理自动化。
我们把业力 ， 茉莉花和所有相应的身体套装
npm i -D karma karma-jasmine jasmine karma-typescript karma-chrome-launcher @types/jasmine ./node_modules/.bin/karma init
我们稍微修改了karma.conf.js并立即配置覆盖率的工作
karma.conf.js karmaTypescriptConfig : { include: ["./src/**/*.ts", "./tests/**/*.spec.ts"], tsconfig: "./tsconfig.json", reports: { "html": "coverage", "lcovonly": { directory: './coverage', filename: '../lcov.dat' } }, coverageOptions: { threshold: { global: { statements: 60, branches: 60, functions: 60, lines: 60, excludes: [] }, file: { statements: 60, branches: 60, functions: 60, lines: 60, excludes: [], overrides: {} } } }, }
并且，当然，不要忘记向package.json添加新命令
package.json
"test": "karma start"
如果您正在使用或计划使用CI，则最好放置HeadlessChrome ：
npm i -D puppeteer
并预先配置Karma（ChromeHeadless上的Chrome修复程序）以及其他功能。 可以在演示存储库中查看编辑。
运行测试，检查一切正常。 同时，检查覆盖率报告（位于覆盖率文件夹中）并将其从版本控制中删除，存储库中不需要它。
报告：
提交风格
提交也可以是统一的（同时，如果你做得过大，则将某人带到热点，所以最好不要狂热）。 为此，我接受了commitizen 。 它以对话的形式工作，支持常规的changelog格式（您可以从其提交中创建一个changelog），并且有一个VsCode 插件
npm i -D commitizen npm i -D cz-conventional-changelog
cz-conventional-changelog是一个适配器，负责问题，并负责提交的格式
将新命令添加到脚本部分
"commit":"git-cz"
还有一个新的package.json部分-commitizen的配置
"config": { "commitizen": { "path": "./node_modules/cz-conventional-changelog" } }
带有commitizen的对话框如下所示：
该文件
现在到文档。 我们将提供两种类型的文档-来自代码和提交。 对于代码中的文档，我选择了typedoc （类似于esdoc，但使用TypeScript）。 设置和工作非常简单。 最主要的是不要忘记从版本控制中删除他的工作结果。
npm i typedoc -D
并更新package.json
package.json
"doc": "typedoc --out docs/src/ --readme ./README.md"
--readme标志将强制将自述文件包含在主文档页面中，这很方便。
第二种类型的文档是changelog， 常规的changelog-cli软件包将为我们提供帮助。
npm i -D conventional-changelog-cli
package.json
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s"
从角度来看，只有格式，仅此而已。 现在，为了更新更改日志，只需运行npm运行更改日志即可。 最主要的是仔细编写提交。 好吧，我们总是编写完美的提交，所以这应该不是问题。
建立
由于我们的软件包也应适用于JavaScript，因此我们需要将TypeScript转换为JavaScript。 另外，最好做成一个缩小的捆，以防万一。 为此，我们需要uglifyjs和一些小的package.json
npm i -D uglifyjs
package.json
"clean":"rmdir dist /S /Q", "build": "tsc --p ./ --sourceMap false", "bundle": "uglifyjs ./dist/*.js --compress --mangle --output ./dist/index.min.js"
顺便说一句，如果您想控制项目的大小，还有两个有趣的软件包
它们也可以集成在提交/推送/发布过程中，以保持可接受的捆绑包大小。 非常非常有帮助。
自动化技术
好吧，我们已经采取了基本步骤，现在一切都需要自动化，否则工作将变得很不方便。
为此，我们还需要另一个沙哑包。 它重写git钩子，并从package.json调用关联的命令。 例如，当您提交时，precommit将起作用，push-prepush等。 如果脚本返回错误，则提交将失败。
npm i -D husky
package.json
"precommit":"npm run prettier", "prepush": "call npm run lint && call npm run test"
这里有一个重要的细微差别，调用语法的使用不是跨平台的，并且不会在unix系统上起飞。 因此，如果您想诚实地做所有事情，则还必须安装npm-run-all软件包，它的功能相同，但跨平台的。
过帐
好了，我们来看一下（尽管是空的）软件包的发布。 让我们想想从出版物中得到什么？
- 再次测试一切
- 收集构建工件
- 收集文件
- 提升版本
- 触发标签
- 提交给npm
双手全力以赴-伤心。 或者您忘记了某些东西，或者您需要编写清单。 也有必要实现自动化。 您可以放入另一个软件包- 释放 。 您可以使用npm本身的本机钩子-像这样的预版本，版本，后版本：
"preversion": "npm run test", "version": "call npm run clean && call npm run build && npm run bundle && call npm run doc && call npm run changelog && git add . && git commit -m 'changelogupdate'
仍然需要为package.json指定包含在包中的内容，入口点和类型的路径（不要忘记在tsconfig.json中指定--declaration标志来获取d.ts文件）
package.json
"main": "./dist/index.min.js", "types": "./dist/index.d.ts", "files": [ "dist/", "src/", "tests/" ]
好吧，这似乎就是全部。 现在足够了
npm version ... npm publish
其他一切将自动完成。
红利
另外，有一个示例存储库 ，使用travis-ci支持所有这些+ CI。 让我提醒您，在这里配置了HeadlessChrome，因此，如果这对您很重要，建议您在此处进行配置。
致谢
非常感谢Alexei Volkov关于JsFest的报告，该报告成为本文的基础。
感谢max7z ， indestructible ， justboris阐明了可以省略到本地依赖项的路径。
还有一些统计
- 节点模块大小：444 MB（NTFS）
- 第一层依赖项的数量：17
- 使用的软件包总数：643
有用的链接