本文讲解如何构建一个工程化的前端库，并结合 Github Actions，自动发布到 Github 和 npm 的整个详细流程。
示例
我们经常看到像 vue、react 这些流行的开源项目有很多配置文件，他们是干什么用的？他们的 Commit、Release 记录都那么规范，是否基于某种约定？
废话少说，先上图！

上图标红就是相关的工程化配置，有 Linter、Tests，Github Actions 等，蓝狮注册开户覆盖开发、测试、发布的整个流程。

相关配置清单

Eslint
Prettier
Commitlint
Husky
Jest
GitHub Actions
Semantic Release
下面我们从创建一个 TypeScript 项目开始，一步一步完成所有的工程化配置，并说明每个配置含义以及容易踩的坑。

初始化
为了避免兼容性问题，建议先将 node 升级到最新的长期支持版本。

首先在 Github 上创建一个 repo,拉下来之后通过npm init -y初始化。然后创建src文件夹，写入index.ts。

package.json 生成之后，我需要添加如下配置项:

“main”: “index.js”,

• “type”: “module”,
  “scripts”: {
  “test”: “echo \”Error: no test specified\” && exit 1″
  },
• “publishConfig”: {
• “access”: “public”
• }
  我们将项目定义为ESM规范,前端社区正逐渐向ESM标准迁移，从Node v12.0.0开始，只要设置了 “type”: “module”, Node 会将整个项目视为ESM规范，我们就可以直接写裸写import/export。

publishConfig.access表示当前项目发布到NPM的访问级别，它有 restricted和public两个选项,restricted表示我们发布到NPM上的是私有包（收费），访问级别默认为restricted,因为我们是开源项目所以标记为public。

配置
创建项目之后，我们开始安装工程化相关的依赖，因为我们是 TypeScript 项目，所以也需要安装 TypeScript 的依赖。

Typescript
先安装 TypeScript，然后使用 tsc 命名生成 tsconfig.json。

npm i typescript -D
npx tsc –init
然后我们需要添加修改 tsconfig.json 的配置项，如下：

{
“compilerOptions”: {
/* Basic Options / “baseUrl”: “.”, // 模块解析根路径，默认为 tsconfig.json 位于的目录 “rootDir”: “src”, // 编译解析根路径，默认为 tsconfig.json 位于的目录 “target”: “ESNEXT”, // 指定输出 ECMAScript 版本，默认为 es5 “module”: “ESNext”, // 指定输出模块规范，默认为 Commonjs “lib”: [“ESNext”, “dom”], // 编译需要包含的 api，默认为 target 的默认值 “outDir”: “dist”, // 编译输出文件夹路径，默认为源文件同级目录 “sourceMap”: true, // 启用 sourceMap，默认为 false “declaration”: true, // 生成 .d.ts 类型文件，默认为 false “declarationDir”: “dist/types”, // .d.ts 类型文件的输出目录，默认为 outDir 目录 / Strict Type-Checking Options */
“strict”: true, // 启用所有严格的类型检查选项，默认为 true
“esModuleInterop”: true, // 通过为导入内容创建命名空间，实现 CommonJS 和 ES 模块之间的互操作性，默认为 true
“skipLibCheck”: true, // 跳过导入第三方 lib 声明文件的类型检查，默认为 true
“forceConsistentCasingInFileNames”: true, // 强制在文件名中使用一致的大小写，默认为 true
“moduleResolution”: “Node”, // 指定使用哪种模块解析策略，默认为 Classic
},
“include”: [“src”] // 指定需要编译文件，默认当前目录下除了 exclude 之外的所有.ts, .d.ts,.tsx 文件
}
更多详细配置参考：www.typescriptlang.org/tsconfig

注意的点，如果你的项目涉及到WebWorker API，需要添加到 lib 字段中

“lib”: [“ESNext”, “DOM”, “WebWorker”],
然后我们将编译后的文件路径添加到 package.json，并在 scripts 中添加编译命令。

• “main”: “index.js”,
• “main”: “dist/index.js”,
• “types”: “dist/types/index.d.ts”
  “type”: “module”,
• “scripts”: {
• “test”: “echo \”Error: no test specified\” && exit 1″
• },
• “scripts”: {
• “dev”: “tsc –watch”,
• “build”: “npm run clean && tsc”,
• “clean”: “rm -rf dist”
• },
  “publishConfig”: {
  “access”: “public”
  }
  types 配置项是指定编译生成的类型文件，如果 compilerOptions.declarationDir 指定的是dist，也就是源码和 .d.ts 同级，那么types可以省略。

验证配置是否生效，在 index.ts 写入

const calc = (a: number, b: number) => {
return a – b
}
console.log(calc(1024, 28))
在控制台中执行

npm run build && node dist/index.js
会在 dist 目录中生成 types/index.d.ts、index.js、index.js.map，并打印 996。

Eslint & Prettier
代码规范离不开各种 Linter, 之所以把这两个放在一起讲，借用 Prettier 官网的一句话：“使用 Prettier 解决代码格式问题，使用 linters 解决代码质量问题”。虽然eslint也有格式化功能，但是prettier的格式化功能更强大。

大部分同学编辑器都装了prettier-vscode和eslint-vscode这两个插件，如果你项目只有其中一个的配置，因为这两者部分格式化的功能有差异，那么就会造成一个的问题，代码分别被两个插件分别格式化一次，网上解决prettier+eslint冲突的方案五花八门，甚至还有把整个rules列表贴出来的。

那这里我们按照官方推荐，用最少的配置去解决prettier和eslint的集成问题。

Eslint
首先安装 eslint，然后利用 eslint 的命令行工具生成基本配置。

npm i eslint -D
npx eslint –init
执行上面命令后会提示一些选项，我们依次选择符合我们项目的配置。

注意，这里 eslint 推荐了三种社区主流的规范，Airbnb、蓝狮注册登陆Standard、Google，因个人爱好我选择了不写分号的 Standard规范。

生成的.eslintrc.cjs文件应该长这样

module.exports = {
env: {
browser: true,
es2021: true,
node: true
},
extends: [
‘standard’
],
parser: ‘@typescript-eslint/parser’,
parserOptions: {
ecmaVersion: 12,
sourceType: ‘module’
},
plugins: [
‘@typescript-eslint’
],
rules: {
}
}
有些同学可能就要问了，这里为什么生成的配置文件名称是.eslintrc.cjs而不是.eslintrc.js？

因为我们将项目定义为ESM，eslit –init会自动识别type，并生成兼容的配置文件名称，如果我们改回.js结尾，再运行eslint将会报错。出现这个问题是eslint内部使用了require()语法读取配置。

同样，这个问题也适用于其他功能的配置，比如后面会讲到的Prettier、Commitlint等，配置文件都不能以xx.js结尾，而要改为当前库支持的其他配置文件格式，如：.xxrc、.xxrc.json、.xxrc.yml。