前言

當(dāng)一個(gè)項(xiàng)目越來(lái)越大，但是團(tuán)隊(duì)對(duì)于項(xiàng)目目錄配置、命名風(fēng)格、模塊劃分、工程腳本等方面沒有做好完備的團(tuán)隊(duì)規(guī)范時(shí)，就會(huì)面臨各種方法應(yīng)用千人千面，接手和維護(hù)的心智負(fù)擔(dān)大的問題，其中scripts配置就是一個(gè)迭代不那么容易收斂的一項(xiàng)配置。

比如張三某天開發(fā)了一段腳本，寫入xxx配置進(jìn)行使用(其實(shí)也是一段很有用的腳本)，除非項(xiàng)目有完善的開發(fā)文檔，否則后來(lái)的人根本不知道有這個(gè)功能，甚至根本不會(huì)想到去用，或者因?yàn)椴恢蓝秩ブ匦略燧喿?..

緣和？

最近在接手一個(gè)迭代了很久的項(xiàng)目時(shí)，上手看到的package.json是這樣的：

"scripts":?{
??"analyze":?"cross-env?ANALYZE=1?umi?build",
??"start":?"cross-env?UMI_ENV=dev?umi?dev",
??"dev":?"npm?run?start:dev",
??"start:dev":?"cross-env?REACT_APP_ENV=dev?MOCK=none?UMI_ENV=dev?umi?dev",
??"start:no-mock":?"cross-env?MOCK=none?UMI_ENV=dev?umi?dev",
??"start:no-ui":?"cross-env?UMI_UI=none?UMI_ENV=dev?umi?dev",
??"start:pre":?"cross-env?REACT_APP_ENV=pre?UMI_ENV=pre?umi?dev",
??"start:test":?"cross-env?REACT_APP_ENV=test?MOCK=none?UMI_ENV=test?umi?dev",
??"start:lcic":?"cross-env?REACT_APP_ENV=dev?MOCK=none?UMI_ENV=lcic?umi?dev",
??"build:test":?"cross-env?UMI_ENV=test?umi?build",
??"build:pt":?"cross-env?UMI_ENV=pt?umi?build",
??"build:pre":?"cross-env?UMI_ENV=pre?umi?build",
??"build:prod":?"cross-env?UMI_ENV=prod?umi?build",
??"build:canary":?"cross-env?UMI_ENV=canary?umi?build",
??"build:hw":?"cross-env?UMI_ENV=hw?umi?build",
??"build:ms":?"cross-env?UMI_ENV=ms?umi?build",
??"deploy":?"npm?run?site?&&?npm?run?gh-pages",
??"gh-pages":?"gh-pages?-d?dist",
??"i18n-remove":?"pro?i18n-remove?--locale=zh-CN?--write",
??"postinstall":?"umi?g?tmp",
??"lint":?"umi?g?tmp?&&?npm?run?lint:js?&&?npm?run?lint:style?&&?npm?run?lint:prettier",
??"lint-staged":?"lint-staged",
??"lint-staged:js":?"eslint?--ext?.js,.jsx,.ts,.tsx?",
??"lint:fix":?"eslint?--fix?--cache?--ext?.js,.jsx,.ts,.tsx?--format=pretty?./src?&&?npm?run?lint:style",
??"lint:js":?"eslint?--cache?--ext?.js,.jsx,.ts,.tsx?--format=pretty?./src",
??"lint:prettier":?"prettier?--check?"src/**/*"?--end-of-line?auto",
??"lint:style":?"stylelint?--fix?"src/**/*.less"?--syntax?less",
??"openapi":?"umi?openapi",
??"precommit":?"",
??"prettier":?"prettier?-c?--write?"src/**/*"",
??"pretest":?"node?./tests/beforeTest",
??"test":?"umi?test",
??"test:all":?"node?./tests/run-tests.js",
??"test:component":?"umi?test?./src/components",
??"tsc":?"tsc?--noEmit",
??"prepare":?"husky?install"
},

不知道你看到這樣的配置第一時(shí)間反應(yīng)是怎樣的，我的感受是“頭皮發(fā)麻”。問題是，這些腳本分別是什么作用？什么場(chǎng)景下用？

如果注釋就好了對(duì)不對(duì)

可是package.json它不允許寫注釋啊！

嘗試

有沒有可能，我們可以像以下這樣維護(hù)一個(gè)項(xiàng)目的scritps呢？這樣接手的人也清楚的知道每個(gè)命令代表什么含義，同時(shí)也能夠單獨(dú)維護(hù)甚至復(fù)用在多個(gè)項(xiàng)目上。

//?假如有這么一個(gè)配置文件
[{
??cmd:?'start:dev',
??script:?'cross-env?REACT_APP_ENV=dev?max?dev',
??desc:?'啟動(dòng)本地開發(fā)環(huán)境，代理開發(fā)環(huán)境API',
},
?{
???cmd:?'start:test',
???script:?'cross-env?REACT_APP_ENV=test?max?test',
???desc:?'啟動(dòng)本地開發(fā)環(huán)境，代理測(cè)試環(huán)境API',
?}]

想法感覺還可以，但是怎么實(shí)現(xiàn)呢？粗略的想象一下先：

想法1: 能不能攔截npm run xxx動(dòng)作，讓執(zhí)行xxx時(shí)去執(zhí)行自定義的配置文件中的命令而不是package.json

想法2: 還是用配置，既然想要優(yōu)化這個(gè)過程，能不能只執(zhí)行 app xxx (app假設(shè)是我要做的這個(gè)工具)，那run也省掉了啊

結(jié)論是：

• 想法1經(jīng)過一番搜刮資源和查找npm文檔，發(fā)現(xiàn)并沒有所謂運(yùn)行npm run xxx之前可以介入的鉤子，因此直接破滅
• 想法2顯然更好一點(diǎn)，但是app這個(gè)腳本就得裝在全局了，否則實(shí)現(xiàn)不了 app xxx，要么就只能裝在項(xiàng)目里通過npx app xxx去調(diào)用

期間還了解了scripty這個(gè)插件，發(fā)現(xiàn)它的過程很雞肋，相當(dāng)于把命令和腳本寫了兩遍，what？怎么可能，我那么懶！

因此經(jīng)過嘗試，只能采取想法2去實(shí)現(xiàn)這個(gè)功能了。

盤點(diǎn)需求

如上文的思路，一份配置文件肯定是必要的，那么定義的形態(tài)就以上文的為基準(zhǔn)了。

• 我希望可以提供針對(duì)不同構(gòu)建工具/平臺(tái)的通用命令集，比如本地啟動(dòng)命令

比如對(duì)于vite，通常是這樣的：vite

對(duì)于webpack，通常是這樣的：

webpack-dev-server --mode development

對(duì)于umi，最常見的是這樣的：

cross-env UMI_ENV=dev umi dev

因此對(duì)于這些每個(gè)項(xiàng)目必備的命令，需要默認(rèn)支持，就不用單獨(dú)去寫了

• 既然我都要借助這個(gè)工具去提升開發(fā)體驗(yàn)了，那對(duì)應(yīng)的提示是不是得到位，接手的人一步就能知道所有命令的作用，比如：

• 我能不能直接對(duì)老項(xiàng)目直接生成一套標(biāo)準(zhǔn)配置，我再去補(bǔ)充desc呢

實(shí)現(xiàn)

實(shí)現(xiàn)過程很簡(jiǎn)單，最終就是直接采用child_process.exec去執(zhí)行了原始腳本：

executeScript(cmd:?string)?{
??exec(cmd,?(err,?sto)?=>?{
????if?(err)?{
??????Log.error(err.stack)
????}?else?{
??????Log.info(sto)
????}
??})
}

健壯性目前還比較欠缺，僅實(shí)現(xiàn)了上述幾個(gè)需求點(diǎn)的基礎(chǔ)功能，后續(xù)會(huì)進(jìn)行完善。想要了解原理的可以看源碼，整體實(shí)現(xiàn)就只有100多行代碼，如有需要可以進(jìn)行二次改造在企業(yè)內(nèi)部推廣使用。

使用

安裝

npm i npm-scripts-proxy -g

生成模板

nsp init

寫模板

//?nsp.config.mjs
import?{?defineNSPConfig,?presets?}?from?'npm-scripts-proxy'
export?default?defineNSPConfig({
??scripts:?[
????{
??????cmd:?'test',
??????script:?'echo?"Error:?no?test?specified"',
??????desc:?'測(cè)試程序',
????},
????{
??????cmd:?'build:test',
??????script:?'node?build.js',
??????desc:?'打包測(cè)試環(huán)境',
????}
??],
??extends:?presets.vite,
})

運(yùn)行命令

nsp xxx

總結(jié)

其實(shí)到最后發(fā)現(xiàn)，這個(gè)工具就解決了一個(gè)問題，那就是標(biāo)題提出的問題，可能它不是最好的解決方案，但是項(xiàng)目一定是越做越大，必然是避免不了冗余且復(fù)雜的。而如果在開發(fā)體驗(yàn)層面可以有一點(diǎn)點(diǎn)提升，省去我們接手項(xiàng)目時(shí)的一些“頭皮發(fā)麻”的體驗(yàn)，寫代碼的心情應(yīng)該也會(huì)好一點(diǎn)吧。

最近在看美團(tuán)Rome的演進(jìn)史時(shí)，負(fù)責(zé)人講到一些關(guān)于Rome在提升開發(fā)體驗(yàn)層面的考慮，感覺很不錯(cuò)，拋開提升效率從而實(shí)現(xiàn)為企業(yè)降本增效不談，“開發(fā)體驗(yàn)”何嘗不是一個(gè)很重要且值得關(guān)注的事情呢。

一個(gè)問題

通過實(shí)現(xiàn)過程可以知道，這個(gè)方案其實(shí)就是間接的去執(zhí)行了npm run xxx，從而不必維護(hù)package.json中的配置，改去維護(hù)體驗(yàn)更好的配置方式。帶來(lái)的問題是，已有的CI構(gòu)建流程就需要替換，如果項(xiàng)目很多那就需要花相應(yīng)的成本去改造，因此實(shí)際應(yīng)用還需要綜合評(píng)估一下才行，不過它確實(shí)有效的解決了一開始提到的問題，是一個(gè)值得嘗試的方案。興趣的朋友可以去看源碼，有更好方案的也可以評(píng)論區(qū)留言一下，讓路過的開發(fā)者也借鑒一下。

查看源碼

以上就是一文詳解如何使npm-scripts更好維護(hù)的詳細(xì)內(nèi)容，更多關(guān)于npm-scripts維護(hù)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論