隨著前端的發(fā)展，越來越多的工具庫、方法被用在日常研發(fā)流程中，這大大提升了業(yè)務(wù)開發(fā)的效率，而隨著各類自動(dòng)化流程的建設(shè)，開發(fā)同學(xué)也不再需要關(guān)注到每一個(gè)細(xì)節(jié)。前段時(shí)間項(xiàng)目階段性交付，在推進(jìn)的過程中也做了不少嘗試，雖然從長期看，這類工作最后可能都該收斂到基礎(chǔ)設(shè)施部門或者標(biāo)準(zhǔn)的自動(dòng)化流程中去，但并不妨礙我通過實(shí)踐來落實(shí)一些對項(xiàng)目開發(fā)的思考和想法。

成都創(chuàng)新互聯(lián)是一家專業(yè)提供新民企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、網(wǎng)站建設(shè)、H5網(wǎng)站設(shè)計(jì)、小程序制作等業(yè)務(wù)。10年已為新民眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設(shè)計(jì)公司優(yōu)惠進(jìn)行中。

如果你是一名有經(jīng)驗(yàn)的開發(fā)者，可以直接跳到文章末尾，「總結(jié)」一章有對全文內(nèi)容的精簡描述。

接下來，我來分享下在項(xiàng)目開發(fā)中嘗試的一些自動(dòng)化和提效實(shí)踐。本文在撰寫中涉及的 UI 框架主要以 create-react-app 所產(chǎn)生的 React 項(xiàng)目為主，會(huì)輔以部分其他框架的解決方案以說明。

新建項(xiàng)目第一步：腳手架

如果你的項(xiàng)目選型是 Angular 的話，那么選擇不多可以直接上 Angular CLI；如果是 React 或 Vue 的話，那么會(huì)有不少腳手架可以選擇，國內(nèi)很多開發(fā)者都有開源不同方案。其中，大多方案會(huì)有一些組件庫、開源庫的綁定，如果你希望一個(gè)更加自由的框架搭建，官方腳手架 create-create-app (CRA) 肯定會(huì)是第一選擇。

通過 npx 執(zhí)行如下命令，我們可以通過 CRA 快速創(chuàng)建一個(gè) TypeScript 項(xiàng)目：

npx create-react-app project --template typescript

但隨著 CRA 的發(fā)展，官方腳手架也將原來暴露在模版中的越來越多細(xì)節(jié)封裝到 react-scripts 包里，簡單舉個(gè)例子，比如你想修改項(xiàng)目 webpack 構(gòu)建流程，用官方模版無法直接上手。

官方模版提供了 npm run eject 命令，執(zhí)行這個(gè)命令會(huì)將潛藏的一系列配置文件和一些依賴項(xiàng)都“彈出”到項(xiàng)目中，然后就可以由你自己完全控制增刪，但是該操作是不可逆的。在配置文件被“彈出”后，你后續(xù)將無法跟隨官方的腳步去升級(jí)項(xiàng)目所使用的 react-script 版本了。

那么，如果你想要一個(gè)可以覆蓋配置，但又與官方版本保持同步的方案，則可以試試 craco https://github.com/dilanx/craco

樣式隔離方案：CSS Modules

這一部分接著上文繼續(xù)。這可能是一個(gè)已經(jīng)被大家熟知且默認(rèn)開啟的選項(xiàng)了，其起源也在于對組件樣式的隔離需求，且如果你的項(xiàng)目是一個(gè)CRA 官方其實(shí)已經(jīng)支持對 CSS Modules 的啟用，按照規(guī)定的格式命名你的樣式文件，CRA 便可自動(dòng)對樣式進(jìn)行解析處理。

但如前文所述，如果你想做一些樣式 loader 的修改，就比如默認(rèn)的解析方式不支持樣式變量的駝峰式命名。要達(dá)到目的，你可以在集成 craco 后在配置 craco.config.js 中這么寫，擴(kuò)充 css loader 配置選項(xiàng)：

module.exports = {
  style: {
    css: {
      mode: "extends",
      loaderOptions: {
        modules: {
          auto: true,
          exportLocalsConvention: 'camelCaseOnly',
        },
      },
    },
  },
};

當(dāng)然，當(dāng)我們在 TypeScript 文件中引用 CSS Modules 變量時(shí)，由于 TypeScript 并不知道除了 .ts 以及 .tsx 文件外的文件內(nèi)容，為了防止 IDE 在語法檢查上報(bào)錯(cuò)，我們還需要針對特定文件后綴聲明下環(huán)境變量。針對 CRA 新建的項(xiàng)目，你可以簡單建立一個(gè) react-app-env.d.ts 文件來補(bǔ)充上如下說明：

/// 
/// 
/// 
/// 

declare module '*.module.css' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module '*.module.scss' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module '*.module.sass' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

此外，通過 craco 你還可以修改些其他內(nèi)容，比如配置 babel 不對 ES6 模塊做轉(zhuǎn)譯、修改打包路徑、自定義熱更新方案等等。

ESLINT 代碼檢查：兩個(gè)自定義 lint 場景分享

為了保證統(tǒng)一一致的代碼風(fēng)格，比如在項(xiàng)目中避免使用 var ，我們可以引入 eslint rules 對提交的代碼進(jìn)行規(guī)范。當(dāng)然，如今大多數(shù)腳手架在新建項(xiàng)目時(shí)，應(yīng)該都替你集成好了 eslint，要么是 .eslintrc.json、.eslintrc.js 或者直接在 package.json 中添加 eslintConfig 屬性開干。

除了開啟默認(rèn)的規(guī)則集外，在開發(fā)過程中，為了讓項(xiàng)目在多人之間能夠更高效地推進(jìn)協(xié)作開發(fā)，肯定有不少細(xì)節(jié)需要處理，這里我簡單分享兩例。

第一點(diǎn)，當(dāng)我們對代碼做了一些增刪操作，就可能產(chǎn)生冗余的 import 聲明，這個(gè)時(shí)候我們當(dāng)然希望它在提交時(shí)被刪除。

在 eslint 中，插件可以暴露額外的規(guī)則以供使用。如果要達(dá)到我們剛剛說的目的，這個(gè)時(shí)候可以引入 unused-imports 插件對 es6 imports 進(jìn)行代碼檢查（比如對于未使用到的 import 聲明進(jìn)行 error 提示）：

{
  "plugins": ["unused-imports"],
  "rules": {
    "no-unused-vars": "off",
    "unused-imports/no-unused-imports": "error",
    "unused-imports/no-unused-vars": [
      "warn",
      { "vars": "all", "varsIgnorePattern": "^_", "args": "after-used", "argsIgnorePattern": "^_" }
    ]
  }
}

借助 IDE 或者 IDE 插件，我們還可以前置到每次保存時(shí)執(zhí)行對 import 引用的清理。

多人協(xié)作中還容易出現(xiàn)一類問題，那就是代碼沖突。當(dāng)多人同時(shí)修改一個(gè)文件時(shí)，可能會(huì)同時(shí)引入新的模塊，如果不對代碼進(jìn)行統(tǒng)一風(fēng)格管理，那么很容易出現(xiàn)“import 沖突”。為了解決這個(gè)問題，可以引入 simple-import-sort 插件，插件還支持對 export 進(jìn)行排序處理：

{
  "plugins": ["simple-import-sort"],
  "rules": {
    "simple-import-sort/imports": "error",
    "simple-import-sort/exports": "error"
  }
}

這樣，在代碼提交前執(zhí)行一遍 eslint —fix 便可完成代碼的檢查與修復(fù)，關(guān)于這部分我們在后面 git hook 一章中詳細(xì)介紹。

其他還有一些與框架相關(guān)的，比如從 React 17 開始，我們可以通過配置 eslint rules 達(dá)到無需在代碼中引入 React 的目的，關(guān)于這一部分的實(shí)現(xiàn)可以參考 React 官方指導(dǎo) ，以下為一段簡單的前后代碼對比：

// 以前
import React from 'react';

function App() {
  return 
Hello World
;
}

// 現(xiàn)在
function App() {
  return 
Hello World
;
}

自動(dòng)化環(huán)境配置：git hook 鉤子定義

husky 是一個(gè)為 git 客戶端增加 hook 的工具，可以被用于我們配置本地自動(dòng)化環(huán)境。我們可以安裝 husky 并定制我們需要的 git 鉤子及具體需要執(zhí)行的任務(wù)，這樣可以方便我們在對代碼執(zhí)行 git 操作時(shí)，在特定時(shí)機(jī)對代碼進(jìn)行特定的檢查與處理，常見的鉤子有如下兩個(gè)：

commit-msg - 提交信息鉤子，在執(zhí)行 git commit 或者 git merge 時(shí)觸發(fā)

pre-commit - 預(yù)先提交鉤子，在執(zhí)行 git commit 時(shí)觸發(fā)

如下為一段 husky 安裝和初始化代碼：

npm install husky -D
npx husky-init && npm install 

// 添加任務(wù)一條 commit-msg 鉤子
npx husky add .husky/commit-msg './node_modules/.bin/commitlint --from=HEAD~1'

舉個(gè)例子，比如我們可以結(jié)合 commitlint 工具，在 commit-msg 階段針對 commit 信息進(jìn)行檢查和處理（如上代碼所示），又或者在 pre-commit 階段對將要提交的代碼進(jìn)行格式化操作。

自定義命令調(diào)用：代碼風(fēng)格統(tǒng)一與 commit 信息規(guī)范

不僅是對于開發(fā)代碼，對于 commit 信息來說，五花八門的書寫風(fēng)格，也十分不利于閱讀和維護(hù)，比如，當(dāng)我們需要翻閱歷史提交來定位具體 commit 所帶來的代碼變動(dòng)時(shí)，這依賴于規(guī)范的 commit 信息。借助 commitlint 可以幫助我們達(dá)到這一點(diǎn)。

commitlint 需要配合 husky 一起使用，具體來說，通過 husky 來保證針對具體鉤子的命令配置，通過 commitlint 保證 命令執(zhí)行能夠?qū)?commit msg 信息進(jìn)行特定檢查。一個(gè)簡單的 commitlint 安裝和配置如下：

# 安裝
npm install --save-dev @commitlint/{config-conventional,cli}

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

配置了 commitlint 之后，若是使用默認(rèn)配置，那么只有當(dāng)我們的 commit msg 符合如下規(guī)范時(shí)，commit 操作才能正常完成執(zhí)行，否則中斷（其中 scope 為可選）：

(): description

如果需要自定義規(guī)則，則需要我們更改 commitlint.config.js 文件，為其增添 rules，關(guān)于這一部分可以參考官方文檔 https://commitlint.js.org/ 。

此外，在添加了 commitlint 配置文件后，我們可能會(huì)看到 IDE 對這個(gè)文件的檢查標(biāo)紅，由于在項(xiàng)目構(gòu)建中我們并不關(guān)注該配置文件的格式等內(nèi)容（因?yàn)樗皇菍?commitlint 的簡單配置），所以我們可以在 eslint 配置文件中將其忽略掉。同樣的，如果有其他的文件屬于類似的定位，你也可以一并將其加入：

{
  "ignorePatterns": ["commitlint.config.js"]
}

說完 commit 規(guī)范，我們的代碼格式本身也需要規(guī)范，比如針對 TypeScript 代碼會(huì)有變量命名和排序的規(guī)則，針對 html 模版會(huì)有縮進(jìn)、標(biāo)簽閉合等規(guī)則，這些也可以利用工具結(jié)合 git hook 來實(shí)現(xiàn)，此處，我們介紹下 linter 工具：lint-staged。

lint-staged 是一個(gè)在 git 暫存文件上運(yùn)行 linters 的工具，通過 lint-staged 定制各類文件格式化的操作（主要通過 eslint 和 prettier 保證執(zhí)行）。結(jié)合 pre-commit git hook，我們在此鉤子被觸發(fā)時(shí)執(zhí)行 lint-staged，便能完成對相應(yīng)文件的格式化處理。如何讓工具針對不同類型的文件區(qū)分處理呢？這里可以通過配置達(dá)到目的，即在 pakage.json 中對 lint-staged 字段進(jìn)行聲明：

{
  ...,
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint -c ./.eslintrc.json --fix"
    ],
    "(*.json|.eslintrc|.prettierrc)": [
      "jsonlint --in-place"
    ],
    "*.{s,}css": [
      "prettier --write"
    ],
    "*.{html,md}": [
      "prettier --write"
    ]
  }
}

如上代碼表明，lint-staged 可以針對 JavaScript/TypeScript 類文件執(zhí)行 eslint 處理，針對 json 類文件執(zhí)行 jsonlint 處理，而對樣式文件和 html 文件都用 prettier 處理。

本地開發(fā)代理環(huán)境

從本地開發(fā)的場景來看，最需要完善的一個(gè)功能就是轉(zhuǎn)發(fā) API 請求了，用以規(guī)避可能存在的 CORS 錯(cuò)誤，或者繞開一些請求限制，形式上可以是針對特定請求變更 header 信息，也可以是針對特定請求變更實(shí)際請求的域名與路徑。但無外乎都需要在本地建立一個(gè)代理環(huán)境。前端項(xiàng)目在本地開發(fā)時(shí)，我們可以通過一個(gè)叫做 http-proxy-middleware 的庫來增強(qiáng)本地 dev server 的能力。

通過文檔介紹，我們知道可以通過調(diào)用 createProxyMiddleware API 來構(gòu)造一個(gè)中間件，以供 Node.js 項(xiàng)目使用，針對 express 應(yīng)用可以通過如下配置完成代理服務(wù)器中間件的配置：

import * as express from 'express';
import { createProxyMiddleware } from 'http-proxy-middleware';

const app = express();

app.use(
  '/api',
  createProxyMiddleware({
    target: 'http://www.example.org/api',
    changeOrigin: true,
  })
);

app.listen(3000);

而對于通過 CRA 構(gòu)建的項(xiàng)目，由于 CRA 已經(jīng)做了一些封裝工作，于是在本地開發(fā)時(shí)，我們不再需要顯式地起一個(gè) Node.js 應(yīng)用，而如上對代理中間件地調(diào)用，也可以在指定文件中按照規(guī)范書寫（文件名以及方法簽名需要規(guī)范，此處不列舉，CRA 官方文檔有說明）。

代碼復(fù)用：組件模版與 code snippets

當(dāng)我們新建一個(gè)項(xiàng)目時(shí)，我們會(huì)找腳手架替我們搭建一個(gè)合適的架子，然后我們往里面填充組件、頁面、服務(wù)等等，而針對更細(xì)粒度的代碼，我們同樣可以考慮通過代碼復(fù)用來提升我們的開發(fā)效率，這里的場景主要可以分為兩類：

1. Code snippets 類代碼片段
2. 組件粒度的文件代碼

針對第一類場景，我們在 IDE 中安裝的不少插件都替我們達(dá)到了這個(gè)目的。當(dāng)我們在特定類型的文件中敲出幾個(gè)字母，然后一回車，就能快速生成一段代碼片段。舉個(gè)例子，比如當(dāng)我們使用 RxJS 時(shí)經(jīng)常需要定義 BehaviorSubject 及其 getter & setter，要是輸入 bgs 就能出現(xiàn)如下代碼，便能提高我們在寫一些初始化代碼時(shí)的效率：

/* TODO: 數(shù)據(jù)流定義 */
behaviorName$ = new BehaviorSubject(initialValue);

get behaviorName() {
     return this.behaviorName$;
}

set behaviorName(value: string) {
     this.behaviorName$.next(value);
}

而我們要做的事情就是將 bgs? 和上述代碼（及特定占位符）連接起來，實(shí)現(xiàn)方案可以是 VS Code 插件，比如我之前寫過一個(gè) https://marketplace.visualstudio.com/items?itemName=hijiangtao.tutor-code-snippets ，也可以是 WebStorm 插件或者 live templates。

針對第二類場景，我們需要的往往是指定路徑下一套遵循我們命名規(guī)范的模版、樣式和 TypeScript 邏輯代碼。舉個(gè)例子，在 Angular 項(xiàng)目中，當(dāng)我們新建一個(gè)組件時(shí)，我們需要同時(shí)生成 HTML、JavaScript、CSS 文件并更新離其最近的 *.module.ts 文件：

CREATE projects/src/app/demo/demo.component.css (0 bytes)
CREATE projects/src/app/demo/demo.component.html (19 bytes)
CREATE projects/src/app/demo/demo.component.spec.ts (612 bytes)
CREATE projects/src/app/demo/demo.component.ts (267 bytes)
UPDATE projects/src/app/app.module.ts (1723 bytes)

在 Angular 項(xiàng)目中，我們可以通過 Angular schematics 來很方便的實(shí)現(xiàn)這一目的；而針對 React 或者 Vue 項(xiàng)目，社區(qū)也有不少實(shí)現(xiàn)方案，比如 generate-react-cli 。

如果不借助社區(qū)或者官方方案，要實(shí)現(xiàn)第二類場景所需的工具，也可以自己開發(fā)一個(gè) npm 包并暴露相應(yīng) bin 腳本，然后通過 npx 執(zhí)行來達(dá)到目的，關(guān)于 npx 的介紹可以參考我之前寫過的一篇博文 《記錄一下 npx 的使用場景》 。

版本發(fā)布：發(fā)版與 CHANGELOG 自動(dòng)化

每當(dāng)我們需要上線一個(gè)新需求時(shí)，為了更好的記錄變動(dòng)，我們一般需要發(fā)個(gè)版本，并同時(shí)記錄一些 CHANGELOG，如果能把這部分工作完全自動(dòng)化，毋庸置疑可以提升我們的項(xiàng)目規(guī)范和發(fā)版效率。這里以 standard-version 舉例。我們引入 standard-version 對自動(dòng)打 tag 以及 CHANGELOG 生成進(jìn)行規(guī)范，具體來說，是期望通過 standard-version 達(dá)到如下目的：

• 根據(jù)指定規(guī)則自動(dòng)升級(jí)項(xiàng)目不同級(jí)別（major、minor、patch）的版本并打 tag
• 對比歷史 commit 提交自動(dòng)生成不同版本間的可閱讀、分類的 CHANGELOG 日志

通過配置，我們還可以重命名上文提到的 commit 信息中的 type 字段在 CHANGELOG 中的標(biāo)題展示，如下為一個(gè)示例配置：

module.exports = {
    "types": [
        { "type": "feat", "section": "Features" },
        { "type": "fix", "section": "Bug Fixes" },
        { "type": "test", "section": "Tests" },
        { "type": "doc", "section": "Document" },
        { "type": "build", "section": "Build System" },
        { "type": "ci", "hidden": true }
    ]
}

如下為自動(dòng)生成的 CHANGELOG 示例：

# Changelog

All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.

## [1.11.0](https://git.woa.com/test/project/compare/v1.10.1...v1.11.0) (2022-06-28)

### Features

- 測試 feature 提交 @hijiangtao (merge request !65) ([a091125](https://git.woa.com/test/project/commit/xxx))

### [1.10.1](https://git.woa.com/test/project/compare/v1.10.0...v1.10.1) (2022-06-24)

### Bug Fixes

- 修改 XXX，并新增 YYY (merge request !63) ([e3a01ce](https://git.woa.com/test/project/commit/yyy))

在使用 standard-version 的時(shí)候，默認(rèn)的配置可以滿足絕大部分場景了，但更細(xì)粒度的控制仍需要我們修改命令或者配置。比如，當(dāng)我們在 package.json 中指定了倉庫 url 后，我們便可以在 commit 信息中通過 @ 符號(hào)指定對應(yīng)用戶、通過 # 引用對應(yīng) issue/PR，這些在生成 CHANGELOG 時(shí)都會(huì)被轉(zhuǎn)成對應(yīng)包含鏈接地址的超鏈接，如下列上一些我在開發(fā)中的版本自動(dòng)生成所涉及的應(yīng)用場景及注意事項(xiàng)：

// 首次執(zhí)行（不變更版本）
standard-version -a -- --first-release 

// 但是如果項(xiàng)目版本不符合規(guī)范，還是需要手動(dòng)發(fā)布，因?yàn)樾枰ＷC項(xiàng)目從 v1.0.0 開始
// https://github.com/conventional-changelog/standard-version/issues/131
standard-version -a -- --release-as 1.0.0

// 在 package.json 中確保項(xiàng)目正確配置 repository 對象
repository.url

// 帶通知具體 user 的 commit-msg 
git commit -m "fix: bug produced by @timojiang" 

// 帶 issue 的 commit-msg
git commit -m "fix: implement functionality discussed in issue #2"

總結(jié)

本文從項(xiàng)目初始化選用腳手架開始、樣式隔離、lint 規(guī)則與 git hook 再到模版工具和自動(dòng)化版本日志，介紹了本人在開發(fā)過程中的一些實(shí)踐和思考，旨在指出一個(gè)項(xiàng)目從代碼初始化到交付上線過程中可能涉及到的不同流程中，存在的不同提交效率和自動(dòng)化流程的工作，囿于文章篇幅，沒有針對所有涉及到的流程和工具進(jìn)行詳細(xì)的 API 介紹，但你仍可以針對其中提到的各類關(guān)鍵詞在互聯(lián)網(wǎng)上進(jìn)行搜索和查看。

本文在撰寫時(shí)也盡量針對不同流程換用了普適的一些描述，以保證所提供的方案在替換了具體工具庫后仍是長期可用的，防止文章內(nèi)容受工具的時(shí)效性影響。

全文來看，主要有這么幾點(diǎn)實(shí)踐總結(jié)：

1. 在腳手架的選擇上，你可以使用 create-react-app 或者 umi 等社區(qū)方案，但如果想要更靈活的腳手架，當(dāng)你使用 CRA 的時(shí)候，可以一并考慮 craco；
2. CSS Modules 的作用無需多說，但同樣需要注意 TypeScript 檢查以及你在命名 CSS 變量寫法上的兼容；
3. ESLINT 現(xiàn)在已經(jīng)是大部分項(xiàng)目的標(biāo)配了，如果你的項(xiàng)目涉及多人協(xié)作，可以配置一些額外的 plugin 協(xié)助保持風(fēng)格一致、減少代碼合并沖突。當(dāng)然，在統(tǒng)一代碼風(fēng)格上，還可以通過 husky 定制 git 鉤子與具體需要執(zhí)行的任務(wù)，比如：

1. commit-msg
2. pre-commit

1. 其中通過 lint-staged 在 pre-commit 時(shí)機(jī)定制各類文件格式化的操作（主要用 eslint 和 prettier 保證執(zhí)行），通過 commitlint 保證 commit msg 信息符合規(guī)范。
2. 本地開發(fā)代理環(huán)境在很多團(tuán)隊(duì)是必須的，你可以選用一個(gè)中間件來增強(qiáng)你的 dev server。
3. 我們同樣可以考慮通過代碼復(fù)用來提升我們的開發(fā)效率，這里的場景主要可以分為兩類：code snippets 以及組件級(jí)別的文件修改。
4. 每當(dāng)項(xiàng)目上線，規(guī)范來說，都需要發(fā)版及記錄日志變更，我們可以引入 standard-version 對自動(dòng)打 tag 以及 CHANGELOG 生成進(jìn)行規(guī)范。

文章名稱：前端開發(fā)中的流程自動(dòng)化與提效實(shí)踐
網(wǎng)頁路徑：http://www.dlmjj.cn/article/dhgcios.html