# @code-standard-c/init

> 标准化执行代码

Latest version **1.0.16** (published 2023-07-20) · ISC license · 0 weekly downloads

## Install

```sh
npm install @code-standard-c/init
pnpm add @code-standard-c/init
yarn add @code-standard-c/init
bun add @code-standard-c/init
```

## Health

**Score 15/100 (F)** — status: abandoned.

Positive: no vulnerabilities.

Warnings: low downloads; no types; no esm support.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 1.0.16 |
| Published | 2023-07-20 |
| First published | 2022-11-24 |
| Weekly downloads | 0 |
| License | ISC |
| TypeScript types | none |
| Module format | CommonJS |
| Dependencies | 15 |
| Unpacked size | 25.9 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Author | yk |
| Maintainers | cococo |

## Links

- npm: https://www.npmjs.com/package/@code-standard-c/init
- Repository: git@gitee.com:ykhuahua/code-standard-c
- npm.io page: https://npm.io/package/@code-standard-c/init

## Dependencies (15)

- [ejs](https://npm.io/package/ejs.md) ^3.1.6
- [glob](https://npm.io/package/glob.md) ^7.1.7
- [semver](https://npm.io/package/semver.md) ^7.3.5
- [fs-extra](https://npm.io/package/fs-extra.md) ^10.0.0
- [inquirer](https://npm.io/package/inquirer.md) ^8.1.2
- [user-home](https://npm.io/package/user-home.md) ^3.0.0
- [kebab-case](https://npm.io/package/kebab-case.md) ^1.0.1
- [npminstall](https://npm.io/package/npminstall.md) ^4.11.0
- [@code-standard-c/log](https://npm.io/package/@code-standard-c/log.md) ^1.0.11
- [@code-standard-c/utils](https://npm.io/package/@code-standard-c/utils.md) ^1.0.11
- [@code-standard-c/command](https://npm.io/package/@code-standard-c/command.md) ^1.0.11
- [@code-standard-c/package](https://npm.io/package/@code-standard-c/package.md) ^1.0.13
- [@code-standard-c/request](https://npm.io/package/@code-standard-c/request.md) ^1.0.11
- [@code-standard-c/format-path](https://npm.io/package/@code-standard-c/format-path.md) ^1.0.7
- [@code-standard-c/get-npm-info](https://npm.io/package/@code-standard-c/get-npm-info.md) ^1.0.13

## Recent versions

- 1.0.16 (latest) — 2023-07-20
- 1.0.15 — 2023-07-20
- 1.0.14 — 2023-07-20
- 1.0.13 — 2023-07-19
- 1.0.12 — 2023-07-15
- 1.0.11 — 2023-07-14
- 1.0.10 — 2023-07-14
- 1.0.9 — 2023-07-12
- 1.0.8 — 2022-11-30
- 1.0.7 — 2022-11-30
- 1.0.5 — 2022-11-24

## README

# 编程规范解决方案之 ESLint + Git Hooks

1. 编码规范
2. git 规范

## 编程规范一：代码检测工具 ESLint

## 编程规范二：代码格式化 Prettier

## ESLint 与 Prettier 配合解决代码格式问题

## 编程规范三：约定式提交规范

约定式提交规范要求如下：

```js
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

--------  翻译 -------------

<类型>[可选 范围]: <描述>

[可选 正文]

[可选 脚注]
```

其中 `<type>` 类型，必须是一个可选的值，比如：

1. 新功能：`feat`
2. 修复：`fix`
3. 文档变更：`docs`
4. ....

## Commitizen 规范化提交代码

`commitizen` 仓库名为 [cz-cli](https://github.com/commitizen/cz-cli) ，它提供了一个 `git cz` 的指令用于代替 `git commit`，简单一句话介绍它：

> 当你使用 `commitizen` 进行代码提交（git commit）时，`commitizen` 会提交你在提交时填写所有必需的提交字段！

1. 全局安装`Commitizen`

   ```js
   npm install -g commitizen
   ```

2. 安装并配置 `cz-customizable` 插件

   1. 使用 `npm` 下载 `cz-customizable`

      ```node
      npm i cz-customizable@6.3.0 --save-dev
      ```

   2. 添加以下配置到 `package.json ` 中

      ```json
      ...
        "config": {
          "commitizen": {
            "path": "node_modules/cz-customizable"
          }
        }

      ```

3. 项目根目录下创建 `.cz-config.js` 自定义提示文件

   ```js
   module.exports = {
     // 可选类型
     types: [
       { value: "feat", name: "feat:     新功能" },
       { value: "fix", name: "fix:      修复" },
       { value: "docs", name: "docs:     文档变更" },
       { value: "style", name: "style:    代码格式(不影响代码运行的变动)" },
       {
         value: "refactor",
         name: "refactor: 重构(既不是增加feature，也不是修复bug)",
       },
       { value: "perf", name: "perf:     性能优化" },
       { value: "test", name: "test:     增加测试" },
       { value: "chore", name: "chore:    构建过程或辅助工具的变动" },
       { value: "revert", name: "revert:   回退" },
       { value: "build", name: "build:    打包" },
     ],
     // 消息步骤
     messages: {
       type: "请选择提交类型:",
       customScope: "请输入修改范围(可选):",
       subject: "请简要描述提交(必填):",
       body: "请输入详细描述(可选):",
       footer: "请输入要关闭的issue(可选):",
       confirmCommit: "确认使用以上信息提交？(y/n/e/h)",
     },
     // 跳过问题
     skipQuestions: ["body", "footer"],
     // subject文字长度默认是72
     subjectLimit: 72,
   };
   ```

4. 使用 `git cz` 代替 `git commit`
   使用 `git cz` 代替 `git commit`，即可看到提示内容

## Git Hooks

> 当《提交描述信息》不符合 [约定式提交规范](https://www.conventionalcommits.org/zh-hans/v1.0.0/) 的时候，阻止当前的提交，并抛出对应的错误提示

我们所期望的 **阻止不合规的提交消息**，那么就需要使用到 `hooks` 的钩子函数。

整体的 `hooks` 非常多，当时我们其中用的比较多的其实只有两个：

| Git Hook       | 调用时机                                                                                                                                           | 说明                               |
| :------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- |
| **pre-commit** | `git commit`执行前<br />它不接受任何参数，并且在获取提交日志消息并进行提交之前被调用。脚本`git commit`以非零状态退出会导致命令在创建提交之前中止。 | 可以用`git commit --no-verify`绕过 |
| **commit-msg** | `git commit`执行前<br />可用于将消息规范化为某种项目标准格式。<br />还可用于在检查消息文件后拒绝提交。                                             | 可以用`git commit --no-verify`绕过 |

1. `commit-msg`：可以用来规范化标准格式，并且可以按需指定是否要拒绝本次提交
2. `pre-commit`：会在提交前被调用，并且可以按需指定是否要拒绝本次提交

## 使用 husky + commitlint 检查提交描述是否符合规范要求

1. [commitlint](https://github.com/conventional-changelog/commitlint)：用于检查提交信息
2. [husky](https://github.com/typicode/husky)：是`git hooks`工具

注意：**`npm` 需要在 7.x 以上版本！！！！！**

### commitlint

1. 安装依赖：

   ```
   npm install --save-dev @commitlint/config-conventional@12.1.4 @commitlint/cli@12.1.4

   ```

2. 创建 `commitlint.config.js` 文件

   ```
   echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

   ```

3. 打开 `commitlint.config.js` ， 增加配置项（ [config-conventional 默认配置点击可查看](https://github.com/conventional-changelog/commitlint/blob/master/@commitlint/config-conventional/index.js) ）：

   ```js
   module.exports = {
     // 继承的规则
     extends: ["@commitlint/config-conventional"],
     // 定义规则类型
     rules: {
       // type 类型定义，表示 git 提交的 type 必须在以下类型范围内
       "type-enum": [
         2,
         "always",
         [
           "feat", // 新功能 feature
           "fix", // 修复 bug
           "docs", // 文档注释
           "style", // 代码格式(不影响代码运行的变动)
           "refactor", // 重构(既不增加新功能，也不是修复bug)
           "perf", // 性能优化
           "test", // 增加测试
           "chore", // 构建过程或辅助工具的变动
           "revert", // 回退
           "build", // 打包
         ],
       ],
       // subject 大小写不做校验
       "subject-case": [0],
     },
   };
   ```

**注意：确保保存为 `UTF-8` 的编码格式**，否则可能会出现错误：

安装 `husky`

### husky

1. 安装依赖：

   ```
   npm install husky@7.0.1 --save-dev

   ```

2. 启动 `hooks` ， 生成 `.husky` 文件夹

   ```
   npx husky install

   ```

3. 在 `package.json` 中生成 `prepare` 指令（ **需要 npm > 7.0 版本** ）

   ```
   npm set-script prepare "husky install"

   ```

4. 执行 `prepare` 指令

   ```
   npm run prepare

   ```

5. 执行成功，提示

6. 添加 `commitlint` 的 `hook` 到 `husky`中，并指令在 `commit-msg` 的 `hooks` 下执行 `npx --no-install commitlint --edit "$1"` 指令

   ```
   npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

   ```

不符合规范的 commit 将不再可提交：

## 通过 pre-commit 检测提交时代码规范

在 **`ESLint` 与 `Prettier` 配合解决代码格式问题** 的章节中，我们讲解了如何处理 **本地！代码格式问题。**

但是这样的一个格式处理问题，他只能够在本地进行处理，并且我们还需要 **手动在 `VSCode` 中配置自动保存** 才可以。那么这样就会存在一个问题，要是有人忘记配置这个东西了怎么办呢？他把代码写的乱七八糟的直接就提交了怎么办呢？

所以我们就需要有一种方式来规避这种风险。

那么想要完成这么一个操作就需要使用 `husky` 配合 `eslint` 才可以实现。

我们期望通过 **`husky` 监测 `pre-commit` 钩子，在该钩子下执行 `npx eslint --ext .js,.vue src`** 指令来去进行相关检测：

1. 执行 `npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src"` 添加 `commit` 时的 `hook` （`npx eslint --ext .js,.vue src` 会在执行到该 hook 时运行）

2. 该操作会生成对应文件 `pre-commit`：

3. 关闭 `VSCode` 的自动保存操作

4. 修改一处代码，使其不符合 `ESLint` 校验规则

5. 执行 **提交操作** 会发现，抛出一系列的错误，代码无法提交

6. 想要提交代码，必须处理完成所有的错误信息

## lint-staged 自动修复格式错误

我们通过 `pre-commit` 处理了 **检测代码的提交规范问题，当我们进行代码提交时，会检测所有的代码格式规范** 。

但是这样会存在两个问题：

1. 我们只修改了个别的文件，没有必要检测所有的文件代码格式
2. 它只能给我们提示出对应的错误，我们还需要手动的进行代码修改

那么这一小节，我们就需要处理这两个问题

那么想要处理这两个问题，就需要使用另外一个插件 [lint-staged](https://github.com/okonet/lint-staged) ！

[lint-staged](https://github.com/okonet/lint-staged) 可以让你当前的代码检查 **只检查本次修改更新的代码，并在出现错误的时候，自动修复并且推送**

[lint-staged](https://github.com/okonet/lint-staged) 无需单独安装，我们生成项目时，`vue-cli` 已经帮助我们安装过了，所以我们直接使用就可以了

1. 修改 `package.json` 配置

   ```js
   "lint-staged": {
       "src/**/*.{js,vue}": [
         "eslint --fix",
         "git add"
       ]
     }

   ```

2. 如上配置，每次它只会在你本地 `commit` 之前，校验你提交的内容是否符合你本地配置的 `eslint`规则(这个见文档 [ESLint](https://panjiachen.github.io/vue-element-admin-site/zh/guide/advanced/eslint.html) )，校验会出现两种结果：

   1. 如果符合规则：则会提交成功。
   2. 如果不符合规则：它会自动执行 `eslint --fix` 尝试帮你自动修复，如果修复成功则会帮你把修复好的代码提交，如果失败，则会提示你错误，让你修好这个错误之后才能允许你提交代码。

3. 修改 `.husky/pre-commit` 文件

   ```js
   #!/bin/sh
   . "$(dirname "$0")/_/husky.sh"

   npx lint-staged


   ```

4. 再次执行提交代码

5. 发现 **暂存区中** 不符合 `ESlint` 的内容，被自动修复

## 最终达到了在保存代码时，自动规范化代码格式的目的

---
_Source: https://npm.io/package/@code-standard-c/init · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._