丁聪`s Blog

Verdaccio + Docker搭建npm私有仓库

发表于 2021-06-18

为托管公司内部组件，实现私有化，并且易于管理和更新，使用Verdaccio + Docker搭建npm私有仓库

Docker 安装Verdacico

一、拉取 verdaccio 的 docker 镜像

1	docker pull verdaccio/verdaccio

二、使用docker运行verdaccio

1	docker run -it -d --rm --name verdaccio -p 4873:4873 verdaccio/verdaccio

三、使用命令

// 添加用户 username passward email
npm adduser --registry localst:4873

// 登录
npm login --registry localst:4873

// 发布私有包
npm publish --registry localst:4873

// 设置npm注册表信息
npm set registry http://localhost:4873/

// 增加配置在.npmrc
registry=http://localhost:4873

// 增加配置在package.json
{
  "publishConfig": {
    "registry": "http://localhost:4873"
  }
}

Commit提交规范校验配置

发表于 2021-06-17

Commit message 提交规范（Angular）

一、Commit message 的作用

格式化的Commit message，有几个好处。

提供更多的历史信息，方便快速浏览。
可以过滤某些commit（比如文档改动），便于快速查找信息。
可以直接从commit生成Change log。

二、Commit message 的格式

每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中，Header 是必需的，Body 和 Footer 可以省略。

不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。

2.1 Header

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

（1）type

feat：新功能（feature）

fix：修补bug

docs：文档（documentation）

style：格式（不影响代码运行的变动）

refactor：重构（即不是新增功能，也不是修改bug的代码变动）

test：增加测试

chore：构建过程或辅助工具的变动

如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

（2）scope

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

（3）subject

subject是 commit 目的的简短描述，不超过50个字符。

以动词开头，使用第一人称现在时，比如change，而不是changed或changes

第一个字母小写

结尾不加句号（.）

配置 Commitizen 通过命令行交互生成规范的Commit message

一、安装工具和适配器(规范)

commitizen/cz-cli, 我们需要借助它提供的 git cz 命令替代我们的 git commit 命令, 帮助我们生成符合规范的 commit message.

除此之外, 我们还需要为 commitizen 指定一个 Adapter（适配器）比如: cz-conventional-changelog (一个符合 Angular团队规范的 preset). 使得 commitizen 按照我们指定的规范帮助我们生成 commit message.

1 2	npm install -g commitizen npm install -g cz-conventional-changelog

二、项目中配置使用

执行命令

1	commitizen init cz-conventional-changelog --save --save-exact

执行完毕，项目中的package.json文件，会多出一部分配置信息

{ 
  ... 
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
}

三、使用git cz替代git commit

后面使用到git commit命令时，一律改为使用git cz。这时，就会出现选项，用来生成符合格式的 Commit message。

配置 commitlint&husky 在commit-msg钩子中进行message校验

一、安装配置commitlint

commitlint: 可以帮助我们 lint commit messages, 如果提交的不符合指向的规范, 拒绝提交
需要一份校验的配置, 这里推荐 @commitlint/config-conventional (符合 Angular团队规范).

1	npm install @commitlint/config-conventional @commitlint/cli --save

接着在项目的根目录下新建commitlint.config.js文件，然后写入：

1
2
3

module.exports = {
  extends: ['@commitlint/config-conventional']
}

二、安装配置husky

commitlint配置完毕后需要配置 husky 在commit-msg 钩子中执行commitlint校验

安装husky

1	npm install husky@4.0.0 --save

建议安装4.x版本 6.x版本后配置规则改变，安装6.x版本请自行查找配置方案

在在package.json中配置

"husky": {
    "hooks": {
      "commit-msg": "commitlint -e $GIT_PARAMS"
    }
  }

这段配置的意思是：在’commit-msg’这个钩子内获取commit里的内容进行commitlint检测，如果果该钩子脚本以非零值退出，Git 将放弃提交

三、编写script脚本实现commit失败后提示

添加提示脚本再commit lint失败后进行提示

编写脚本
在当前根目录创建scripts文件夹，里面创建pre-commit.js文件

const chalk = require('chalk');
console.log(
  chalk.red(`commit格式错误，正确示例：git commit -m 'fix: 修复bug'`),
  chalk.green(` 
  type （只允许下列7个标识）：
  feat：新功能（feature）
  fix：修补bug
  docs：文档（documentation）
  style： 格式（不影响代码运行的变动）
  refactor：重构（即不是新增功能，也不是修改bug的代码变动）
  test：增加测试
  chore：构建过程或辅助工具的变动
  `)
)

修改husky的配置

"husky": {
  "hooks": {
    "commit-msg": "commitlint -e $GIT_PARAMS || (node scripts/pre-commit.js&&exit 8)"
  }
}

在commitlint -e $GIT_PARAMS 执行失败后执行 node scripts/pre-commit.js&&exit 8 并退出

ESLint+Prettier代码规范实践

发表于 2020-03-16 更新于 2021-06-16

ESLint&Prettier

ESLint

ESlint 主要对代码格式和代码质量进行检验。早前ESlint只提供warning报告，现在 ESLint 提供了 $ ESLint filename –fix 的命令自动修复部分不符合规范的代码

Prettier

prettier 自动对代码格式进行格式化，prettier 已经逐渐成为业界主流的代码风格格式化工具

代码格式问题通常指的是：单行代码长度、tab长度、空格、逗号表达式等问题。而代码质量问题指的是：未使用变量、三等号、全局变量声明等问题。

ESLint 和 Prettier的配合使用

Q:ESlint 有了fix命令为什么还要配合使用Prettier？
A: ESLint 的规则并不能完全包含 Prettier 的规则,ESlint 主要负责代码规则校验，Prettier 负责格式化代码风格，代码样式，两者分工不同，需要配合使用。

ESLint 和 Prettier 相互合作的时候有一些问题，对于他们交集的部分规则，ESLint 和 Prettier 格式化后的代码格式不一致。导致的问题是：当你用 Prettier 格式化代码后再用 ESLint 去检测，会出现一些因为格式化导致的 warning。

Q: 怎么解决？
A: 在配置 ESLint 的校验规则时候把和 Prettier 冲突的规则 disable 掉，然后再使用 Prettier 的规则作为校验规则。那么使用 Prettier 格式化后，使用 ESLint 校验就不会出现对前者的 warning。

Q: 怎么设置disable掉和Prettier冲突的ESLint规则？

一、安装 eslint-config-prettier 插件

1	npm install --save-dev eslint-config-prettier

二、配置.eslintrc.* 文件

{
    "extends": [
        ...,
        "已经配置的规则",
    +   "prettier"
    ]
}

三、完成上述两步可以实现的是运行 eslint 命令会按照 prettier 的规则做相关校验，但是还是需要分别运行 prettier 和 eslint 命令。社区有一个方案整合了上述两步，在使用 eslint –fix 时候，实际使用 prettier 来替代 eslint 的格式化功能。安装：

1	npm install --save-dev eslint-plugin-prettier

配置.eslintrc.* 文件

{
    "extends": [
        ...,
        "已经配置的规则",
        "plugin:prettier/recommended"
    ]
}

这个时候你运行 eslint –fix 实际使用的是 Prettier 去格式化文件

使用husky lint-staged 强制校验和格式化

我们可以用 husky lint-staged 来在 git commit 前强制代码格式化和代码校验。
我们可以在执行 git commit 时使用husky 和 lint-staged 对本地缓存区内的代码进行 lint校验

1	npm install --save-dev husky lint-staged

配置package.json

 {
  "name": "project-name",
  ...,
  + "husky": {
  +     "hooks": {
  +         "pre-commit": "lint-staged"
  +     }
  + },
  + "lint-staged": {
  +     "src/**/*.{js,jsx,ts,tsx,json,css,scss,md}": [
  +     "eslint --fix",
  +     "git add"
  +     ]
  + },
}