建站
咨詢
售后
建站咨詢
新聞中心
隨著前端的發(fā)展，越來越多的工具庫、方法被用在日常研發(fā)流程中，這大大提升了業(yè)務(wù)開發(fā)的效率，而隨著各類自動化流程的建設(shè)，開發(fā)同學(xué)也不再需要關(guān)注到每一個細(xì)節(jié)。前段時間項目階段性交付，在推進(jìn)的過程中也做了不少嘗試，雖然從長期看，這類工作最后可能都該收斂到基礎(chǔ)設(shè)施部門或者標(biāo)準(zhǔn)的自動化流程中去，但并不妨礙我通過實踐來落實一些對項目開發(fā)的思考和想法。
如果你是一名有經(jīng)驗的開發(fā)者，可以直接跳到文章末尾，「總結(jié)」一章有對全文內(nèi)容的精簡描述。
接下來，我來分享下在項目開發(fā)中嘗試的一些自動化和提效實踐。本文在撰寫中涉及的 UI 框架主要以 create-react-app 所產(chǎn)生的 React 項目為主，會輔以部分其他框架的解決方案以說明。
新建項目第一步：腳手架
如果你的項目選型是 Angular 的話，那么選擇不多可以直接上 Angular CLI；如果是 React 或 Vue 的話，那么會有不少腳手架可以選擇，國內(nèi)很多開發(fā)者都有開源不同方案。其中，大多方案會有一些組件庫、開源庫的綁定，如果你希望一個更加自由的框架搭建，官方腳手架 create-create-app (CRA) 肯定會是第一選擇。
通過 npx 執(zhí)行如下命令，我們可以通過 CRA 快速創(chuàng)建一個 TypeScript 項目：
npx create-react-app project --template typescript
但隨著 CRA 的發(fā)展，官方腳手架也將原來暴露在模版中的越來越多細(xì)節(jié)封裝到 react-scripts 包里，簡單舉個例子，比如你想修改項目 webpack 構(gòu)建流程，用官方模版無法直接上手。
官方模版提供了 npm run eject 命令，執(zhí)行這個命令會將潛藏的一系列配置文件和一些依賴項都“彈出”到項目中，然后就可以由你自己完全控制增刪，但是該操作是不可逆的。在配置文件被“彈出”后，你后續(xù)將無法跟隨官方的腳步去升級項目所使用的 react-script 版本了。
那么，如果你想要一個可以覆蓋配置，但又與官方版本保持同步的方案，則可以試試 craco github.com/dilanx/craco
樣式隔離方案：CSS Modules
這一部分接著上文繼續(xù)。這可能是一個已經(jīng)被大家熟知且默認(rèn)開啟的選項了，其起源也在于對組件樣式的隔離需求，且如果你的項目是一個CRA 官方其實已經(jīng)支持對 CSS Modules 的啟用，按照規(guī)定的格式命名你的樣式文件，CRA 便可自動對樣式進(jìn)行解析處理。
但如前文所述，如果你想做一些樣式 loader 的修改，就比如默認(rèn)的解析方式不支持樣式變量的駝峰式命名。要達(dá)到目的，你可以在集成 craco 后在配置 craco.config.js 中這么寫，擴(kuò)充 css loader 配置選項：
module.exports = {
style: {
css: {
mode: "extends",
loaderOptions: {
modules: {
auto: true,
exportLocalsConvention: 'camelCaseOnly',
},
},
},
},
};當(dāng)然，當(dāng)我們在 TypeScript 文件中引用 CSS Modules 變量時，由于 TypeScript 并不知道除了 .ts 以及 .tsx 文件外的文件內(nèi)容，為了防止 IDE 在語法檢查上報錯，我們還需要針對特定文件后綴聲明下環(huán)境變量。針對 CRA 新建的項目，你可以簡單建立一個 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 代碼檢查：兩個自定義 lint 場景分享
為了保證統(tǒng)一一致的代碼風(fēng)格，比如在項目中避免使用 var，我們可以引入 eslint rules 對提交的代碼進(jìn)行規(guī)范。當(dāng)然，如今大多數(shù)腳手架在新建項目時，應(yīng)該都替你集成好了 eslint，要么是 .eslintrc.json、.eslintrc.js 或者直接在 package.json 中添加 eslintConfig 屬性開干。
除了開啟默認(rèn)的規(guī)則集外，在開發(fā)過程中，為了讓項目在多人之間能夠更高效地推進(jìn)協(xié)作開發(fā)，肯定有不少細(xì)節(jié)需要處理，這里我簡單分享兩例。
第一點，當(dāng)我們對代碼做了一些增刪操作，就可能產(chǎn)生冗余的 import 聲明，這個時候我們當(dāng)然希望它在提交時被刪除。
在 eslint 中，插件可以暴露額外的規(guī)則以供使用。如果要達(dá)到我們剛剛說的目的，這個時候可以引入 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 插件，我們還可以前置到每次保存時執(zhí)行對 import 引用的清理。
多人協(xié)作中還容易出現(xiàn)一類問題，那就是代碼沖突。當(dāng)多人同時修改一個文件時，可能會同時引入新的模塊，如果不對代碼進(jìn)行統(tǒng)一風(fēng)格管理，那么很容易出現(xiàn)“import 沖突”。為了解決這個問題，可以引入 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)于這一部分的實現(xiàn)可以參考 React 官方指導(dǎo)，以下為一段簡單的前后代碼對比：
// 以前
import React from 'react';
function App() {
returnHello World
;
}
// 現(xiàn)在
function App() {
returnHello World
;
}
自動化環(huán)境配置：git hook 鉤子定義
husky 是一個為 git 客戶端增加 hook 的工具，可以被用于我們配置本地自動化環(huán)境。我們可以安裝 husky 并定制我們需要的 git 鉤子及具體需要執(zhí)行的任務(wù)，這樣可以方便我們在對代碼執(zhí)行 git 操作時，在特定時機(jī)對代碼進(jìn)行特定的檢查與處理，常見的鉤子有如下兩個：
- commit-msg - 提交信息鉤子，在執(zhí)行 git commit 或者 git merge 時觸發(fā)
- pre-commit - 預(yù)先提交鉤子，在執(zhí)行 git commit 時觸發(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'
舉個例子，比如我們可以結(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 所帶來的代碼變動時，這依賴于規(guī)范的 commit 信息。借助 commitlint 可以幫助我們達(dá)到這一點。
commitlint 需要配合 husky 一起使用，具體來說，通過 husky 來保證針對具體鉤子的命令配置，通過 commitlint 保證 命令執(zhí)行能夠?qū)?commit msg 信息進(jìn)行特定檢查。一個簡單的 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ī)范時，commit 操作才能正常完成執(zhí)行，否則中斷（其中 scope 為可選）：
( ): description
如果需要自定義規(guī)則，則需要我們更改 commitlint.config.js 文件，為其增添 rules，關(guān)于這一部分可以參考官方文檔 commitlint.js.org/。
此外，在添加了 commitlint 配置文件后，我們可能會看到 IDE 對這個文件的檢查標(biāo)紅，由于在項目構(gòu)建中我們并不關(guān)注該配置文件的格式等內(nèi)容（因為他只是對 commitlint 的簡單配置），所以我們可以在 eslint 配置文件中將其忽略掉。同樣的，如果有其他的文件屬于類似的定位，你也可以一并將其加入：
{
"ignorePatterns": ["commitlint.config.js"]
}說完 commit 規(guī)范，我們的代碼格式本身也需要規(guī)范，比如針對 TypeScript 代碼會有變量命名和排序的規(guī)則，針對 html 模版會有縮進(jìn)、標(biāo)簽閉合等規(guī)則，這些也可以利用工具結(jié)合 git hook 來實現(xiàn)，此處，我們介紹下 linter 工具：lint-staged。
lint-staged 是一個在 git 暫存文件上運行 linters 的工具，通過 lint-staged 定制各類文件格式化的操作（主要通過 eslint 和 prettier 保證執(zhí)行）。結(jié)合 pre-commit git hook，我們在此鉤子被觸發(fā)時執(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ā)的場景來看，最需要完善的一個功能就是轉(zhuǎn)發(fā) API 請求了，用以規(guī)避可能存在的 CORS 錯誤，或者繞開一些請求限制，形式上可以是針對特定請求變更 header 信息，也可以是針對特定請求變更實際請求的域名與路徑。但無外乎都需要在本地建立一個代理環(huán)境。前端項目在本地開發(fā)時，我們可以通過一個叫做 http-proxy-middleware 的庫來增強(qiáng)本地 dev server 的能力。
通過文檔介紹，我們知道可以通過調(diào)用 createProxyMiddleware API 來構(gòu)造一個中間件，以供 Node.js 項目使用，針對 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)建的項目，由于 CRA 已經(jīng)做了一些封裝工作，于是在本地開發(fā)時，我們不再需要顯式地起一個 Node.js 應(yīng)用，而如上對代理中間件地調(diào)用，也可以在指定文件中按照規(guī)范書寫（文件名以及方法簽名需要規(guī)范，此處不列舉，CRA 官方文檔有說明）。
代碼復(fù)用：組件模版與 code snippets
當(dāng)我們新建一個項目時，我們會找腳手架替我們搭建一個合適的架子，然后我們往里面填充組件、頁面、服務(wù)等等，而針對更細(xì)粒度的代碼，我們同樣可以考慮通過代碼復(fù)用來提升我們的開發(fā)效率，這里的場景主要可以分為兩類：
- Code snippets 類代碼片段
- 組件粒度的文件代碼
針對第一類場景，我們在 IDE 中安裝的不少插件都替我們達(dá)到了這個目的。當(dāng)我們在特定類型的文件中敲出幾個字母，然后一回車，就能快速生成一段代碼片段。舉個例子，比如當(dāng)我們使用 RxJS 時經(jīng)常需要定義 BehaviorSubject 及其 getter & setter，要是輸入 bgs 就能出現(xiàn)如下代碼，便能提高我們在寫一些初始化代碼時的效率：
/* TODO: 數(shù)據(jù)流定義 */
behaviorName$ = new BehaviorSubject(initialValue);
get behaviorName() {
return this.behaviorName$;
}
set behaviorName(value: string) {
this.behaviorName$.next(value);
}
而我們要做的事情就是將 bgs 和上述代碼（及特定占位符）連接起來，實現(xiàn)方案可以是 VS Code 插件，比如我之前寫過一個 marketplace.visualstudio.com，也可以是 WebStorm 插件或者 live templates。
針對第二類場景，我們需要的往往是指定路徑下一套遵循我們命名規(guī)范的模版、樣式和 TypeScript 邏輯代碼。舉個例子，在 Angular 項目中，當(dāng)我們新建一個組件時，我們需要同時生成 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 項目中，我們可以通過 Angular schematics 來很方便的實現(xiàn)這一目的；而針對 React 或者 Vue 項目，社區(qū)也有不少實現(xiàn)方案，比如 generate-react-cli。
如果不借助社區(qū)或者官方方案，要實現(xiàn)第二類場景所需的工具，也可以自己開發(fā)一個 npm 包并暴露相應(yīng) bin 腳本，然后通過 npx 執(zhí)行來達(dá)到目的，關(guān)于 npx 的介紹可以參考我之前寫過的一篇博文《記錄一下 npx 的使用場景》。
版本發(fā)布：發(fā)版與 CHANGELOG 自動化
每當(dāng)我們需要上線一個新需求時，為了更好的記錄變動，我們一般需要發(fā)個版本，并同時記錄一些 CHANGELOG，如果能把這部分工作完全自動化，毋庸置疑可以提升我們的項目規(guī)范和發(fā)版效率。這里以 standard-version 舉例。我們引入 standard-version 對自動打 tag 以及 CHANGELOG 生成進(jìn)行規(guī)范，具體來說，是期望通過 standard-version 達(dá)到如下目的：
- 根據(jù)指定規(guī)則自動升級項目不同級別（major、minor、patch）的版本并打 tag
- 對比歷史 commit 提交自動生成不同版本間的可閱讀、分類的 CHANGELOG 日志
通過配置，我們還可以重命名上文提到的 commit 信息中的 type 字段在 CHANGELOG 中的標(biāo)題展示，如下為一個示例配置：
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 }
]
}如下為自動生成的 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 的時候，默認(rèn)的配置可以滿足絕大部分場景了，但更細(xì)粒度的控制仍需要我們修改命令或者配置。比如，當(dāng)我們在 package.json 中指定了倉庫 url 后，我們便可以在 commit 信息中通過 @ 符號指定對應(yīng)用戶、通過 # 引用對應(yīng) issue/PR，這些在生成 CHANGELOG 時都會被轉(zhuǎn)成對應(yīng)包含鏈接地址的超鏈接，如下列上一些我在開發(fā)中的版本自動生成所涉及的應(yīng)用場景及注意事項：
// 首次執(zhí)行（不變更版本）
standard-version -a -- --first-release
// 但是如果項目版本不符合規(guī)范，還是需要手動發(fā)布，因為需要保證項目從 v1.0.0 開始
// https://github.com/conventional-changelog/standard-version/issues/131
standard-version -a -- --release-as 1.0.0
// 在 package.json 中確保項目正確配置 repository 對象
repository.url
// 帶通知具體 user 的 commit-msg
git commit -m "fix: bug produced by @hijiangtao"
// 帶 issue 的 commit-msg
git commit -m "fix: implement functionality discussed in issue #2"
總結(jié)
本文從項目初始化選用腳手架開始、樣式隔離、lint 規(guī)則與 git hook 再到模版工具和自動化版本日志，介紹了本人在開發(fā)過程中的一些實踐和思考，旨在指出一個項目從代碼初始化到交付上線過程中可能涉及到的不同流程中，存在的不同提交效率和自動化流程的工作，囿于文章篇幅，沒有針對所有涉及到的流程和工具進(jìn)行詳細(xì)的 API 介紹，但你仍可以針對其中提到的各類關(guān)鍵詞在互聯(lián)網(wǎng)上進(jìn)行搜索和查看。
本文在撰寫時也盡量針對不同流程換用了普適的一些描述，以保證所提供的方案在替換了具體工具庫后仍是長期可用的，防止文章內(nèi)容受工具的時效性影響。
全文來看，主要有這么幾點實踐總結(jié)：
- 在腳手架的選擇上，你可以使用 create-react-app 或者 umi 等社區(qū)方案，但如果想要更靈活的腳手架，當(dāng)你使用 CRA 的時候，可以一并考慮 craco；
- CSS Modules 的作用無需多說，但同樣需要注意 TypeScript 檢查以及你在命名 CSS 變量寫法上的兼容；
- ESLINT 現(xiàn)在已經(jīng)是大部分項目的標(biāo)配了，如果你的項目涉及多人協(xié)作，可以配置一些額外的 plugin 協(xié)助保持風(fēng)格一致、減少代碼合并沖突。當(dāng)然，在統(tǒng)一代碼風(fēng)格上，還可以通過 husky 定制 git 鉤子與具體需要執(zhí)行的任務(wù)，比如：
a.commit-msg
b,pre-commit
- 其中通過 lint-staged 在 pre-commit 時機(jī)定制各類文件格式化的操作（主要用 eslint 和 prettier 保證執(zhí)行），通過 commitlint 保證 commit msg 信息符合規(guī)范。
- 本地開發(fā)代理環(huán)境在很多團(tuán)隊是必須的，你可以選用一個中間件來增強(qiáng)你的 dev server。
- 我們同樣可以考慮通過代碼復(fù)用來提升我們的開發(fā)效率，這里的場景主要可以分為兩類：code snippets 以及組件級別的文件修改。
- 每當(dāng)項目上線，規(guī)范來說，都需要發(fā)版及記錄日志變更，我們可以引入 standard-version 對自動打 tag 以及 CHANGELOG 生成進(jìn)行規(guī)范。
名稱欄目：現(xiàn)代Web的流程自動化與提效實踐
網(wǎng)頁地址：http://m.fisionsoft.com.cn/article/djpppic.html
