快捷導(dǎo)航

一文詳解如何使npm-scripts更好維護的配置方法

更新時間：2023年06月11日 08:53:56 作者：vannvan

這篇文章主要為大家介紹了如何使npm-scripts更好維護的配置方法詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

前言

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

比如張三某天開發(fā)了一段腳本，寫入xxx配置進行使用(其實也是一段很有用的腳本)，除非項目有完善的開發(fā)文檔，否則后來的人根本不知道有這個功能，甚至根本不會想到去用，或者因為不知道而又去重新造輪子...

緣和？

最近在接手一個迭代了很久的項目時，上手看到的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"
},

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

如果注釋就好了對不對

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

嘗試

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

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

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

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

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

結(jié)論是：

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

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

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

盤點需求

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

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

比如對于vite，通常是這樣的：vite

對于webpack，通常是這樣的：

webpack-dev-server --mode development

對于umi，最常見的是這樣的：

cross-env UMI_ENV=dev umi dev

因此對于這些每個項目必備的命令，需要默認支持，就不用單獨去寫了

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

我能不能直接對老項目直接生成一套標準配置，我再去補充desc呢

實現(xiàn)

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

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

健壯性目前還比較欠缺，僅實現(xiàn)了上述幾個需求點的基礎(chǔ)功能，后續(xù)會進行完善。想要了解原理的可以看源碼，整體實現(xiàn)就只有100多行代碼，如有需要可以進行二次改造在企業(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:?'測試程序',
????},
????{
??????cmd:?'build:test',
??????script:?'node?build.js',
??????desc:?'打包測試環(huán)境',
????}
??],
??extends:?presets.vite,
})

運行命令

nsp xxx

總結(jié)

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

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

一個問題

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

查看源碼

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

您可能感興趣的文章: