PS: 感謝 Lainbo^[1] 和 未覺雨聲^[2] 的指正，css 變量比之前統(tǒng)計(jì)的使用率更高。5月7日編輯。

參考了如下組件庫(kù)，因?yàn)橛行┰O(shè)計(jì)是多個(gè)版本和框架的，這里只討論 Vue3 版本。

• element-plus^[3] - 經(jīng)典中的經(jīng)典，全面支持 Vue 3

• tdesign-vue-next^[4] - 鵝廠優(yōu)質(zhì) UI 組件，配套工具完滿，設(shè)計(jì)工整，文檔清晰

• arco-design-vue^[5]- 字節(jié)跳動(dòng) UI 組件庫(kù)開源，大廠邏輯，設(shè)計(jì)文檔完美

• ant-design-vue^[6] - 螞蟻前端 UI 庫(kù)，面向企業(yè)級(jí)中后臺(tái)

• naive-ui^[7] - 寶藏 Vue UI 庫(kù)，Vue UI 新星，從 Vue 3 起步

• vant^[8] - 有贊團(tuán)隊(duì)開源移動(dòng) UI 組件庫(kù)，全面支持 Vue 3

• nutui^[9] - 京東出品，移動(dòng)端友好，面向電商業(yè)務(wù)場(chǎng)景

• vuetify^[10] - 老牌 Vue UI ，基于谷歌的 Material Design 樣式開發(fā)

• varlet^[11] - Varlet 是一個(gè)基于?Vue3?開發(fā)的 Material 風(fēng)格移動(dòng)端組件庫(kù)，全面擁抱?Vue3?生態(tài)，由社區(qū)建立起來(lái)的組件庫(kù)團(tuán)隊(duì)進(jìn)行維護(hù)。

TypeScript

流行度：100%
這個(gè)流行趨勢(shì)已經(jīng)成必然了，現(xiàn)在面試也有越來(lái)越多的 TS 相關(guān)。

rollbar 是一個(gè)異常監(jiān)控平臺(tái)，rollbar 于 2018 年統(tǒng)計(jì)了前端項(xiàng)目中Top10 的錯(cuò)誤類型^[12]：

這里有很多錯(cuò)誤都是空的或未定義的。如果使用 TypeScript 就可以簡(jiǎn)單的避免這些錯(cuò)誤。

使用 TypeScript 可以避免 80% 的相關(guān)錯(cuò)誤，當(dāng)然 anyScript 不行。。

另外 TypeScript 的優(yōu)勢(shì)不止于此，比如 IDE 的智能提示，項(xiàng)目更容易維護(hù)等等。如果你還沒(méi)有用 過(guò) TS，那最好現(xiàn)在開始嘗試使用。

Monorepo

流行度：55%

包括 vue、Reac、Babel 等越來(lái)越多的項(xiàng)目都開始使用 Monorepo

Monorepo，就是指將所有代碼放到一個(gè)代碼倉(cāng)庫(kù)中的項(xiàng)目管理策略。

Monorepos 的優(yōu)點(diǎn)

• 依賴管理：共享依賴，所有的代碼都在一個(gè)倉(cāng)庫(kù)。版本管理非常方便。
• 代碼復(fù)用：所有的代碼都在一個(gè)倉(cāng)庫(kù)，很容易抽離出各個(gè)項(xiàng)目共用的業(yè)務(wù)組件或工具，并通過(guò) TypeScript 在代碼內(nèi)引用。
• 一致性：所有代碼在一個(gè)倉(cāng)庫(kù)，代碼質(zhì)量標(biāo)準(zhǔn)和統(tǒng)一風(fēng)格會(huì)更容易。
• 透明度：所有人都能看到全部代碼，跨團(tuán)隊(duì)協(xié)作和貢獻(xiàn)更容易。

Monorepos 的缺點(diǎn)

• 性能：代碼越來(lái)越多，Git、IDE 之類的工具會(huì)越來(lái)越卡。
• 權(quán)限：管理文件權(quán)限會(huì)更具挑戰(zhàn)，Git 目錄并沒(méi)有內(nèi)置的權(quán)限管理系統(tǒng)，整個(gè)項(xiàng)目是沒(méi)辦法區(qū)分某些部門開放哪個(gè)項(xiàng)目，某些部門關(guān)閉的。
• 學(xué)習(xí)成本：對(duì)新人來(lái)說(shuō)，項(xiàng)目變大了，學(xué)習(xí)成本自然會(huì)更高。

Monorepo 絕對(duì)不是銀彈，Monorepo 策略也不完美，但某些方面來(lái)說(shuō)確實(shí)解決了一些項(xiàng)目的維護(hù)和開發(fā)體驗(yàn)。

如果你的項(xiàng)目有多個(gè)關(guān)聯(lián)倉(cāng)庫(kù)，或者還在用 submodule 方式管理多個(gè)倉(cāng)庫(kù)，那可以試一試Monorepo。

包管理器

有 55% 使用 非npm，剩下 45% 看不出來(lái)使用什么包管理工具，最主要的是居然都沒(méi)有 lock 文件，這個(gè)是真沒(méi)看懂，作為開源項(xiàng)目不需要統(tǒng)一依賴版本的嗎？

npm v1-v2

1. 初代的 npm 會(huì)導(dǎo)致重復(fù)安裝依賴，比如 A 依賴 C，B 也依賴 C，這時(shí)會(huì)安裝兩次 C。(是安裝兩次，不是下載兩次。會(huì)下載到本地緩存。)
2. 因?yàn)槭菢湫徒Y(jié)構(gòu)，node_modules嵌套層級(jí)過(guò)深(會(huì)導(dǎo)致文件路徑過(guò)長(zhǎng)的問(wèn)題)
3. 模塊實(shí)例不能共享。比如 React 有一些內(nèi)部變量，在兩個(gè)不同包引入的 React 不是同一個(gè)模塊實(shí)例，因此無(wú)法共享內(nèi)部變量，導(dǎo)致一些不可預(yù)知的 bug。

npm v3 / yarn

從 npm3 和 yarn 開始，都來(lái)通過(guò)扁平化依賴的方式來(lái)解決上面的這個(gè)問(wèn)題。

所有的依賴都被拍平到node_modules目錄下，不再有很深層次的嵌套關(guān)系。這樣在安裝新的包時(shí)，根據(jù) node require 機(jī)制，會(huì)不停往上級(jí)的node_modules當(dāng)中去找，如果找到相同版本的包就不會(huì)重新安裝，解決了大量包重復(fù)安裝的問(wèn)題，而且依賴層級(jí)也不會(huì)太深。

但同時(shí)，這樣也帶來(lái)了新的問(wèn)題

1. 幽靈依賴 - package.json里并沒(méi)有寫入的包竟然也可以在項(xiàng)目中使用了。
2. 分身依賴 - 比如 A 和 B 都依賴了 C，但是依賴 C 的版本不一樣，一個(gè)是 1.0.0，一個(gè)是 2.0.0。這時(shí)取決于 A 和 B 在package.json中的位置，使用的 C 有可能是 1.0.0 版本，也可能是 2.0.0 版本。
3. 平鋪減少安裝沒(méi)有減省時(shí)間，因?yàn)樗惴ǖ脑颍瑫r(shí)間居然還增加了。

npm v5 / yarn

該版本引入了一個(gè)lock文件，以解決node_modules安裝中的不確定因素。這使得無(wú)論你安裝多少次，都能有一個(gè)一樣結(jié)構(gòu)的node_modules。

然而，平鋪式的算法的復(fù)雜性，幽靈依賴之類的問(wèn)題還是沒(méi)有解決。

yarn v2 PnP

在 yarn 的 2.x 版本重點(diǎn)推出了 Plug’n’Play（PnP）零安裝模式，放棄了node_modules，更加保證依賴的可靠性，構(gòu)建速度也得到更大的提升。

yarn 2.x 擺脫 node_modules，安裝、模塊速度加載快；所有 npm 模塊都會(huì)存放在全局的緩存目錄下，避免多重依賴；嚴(yán)格模式下子依賴不會(huì)提升，也避免了幽靈依賴。

但是，自建 resolver 處理 Node require 方法，脫離Node現(xiàn)存生態(tài)，兼容性不太好。

pnpm

pnpm 具有安裝速度快、節(jié)約磁盤空間、安全性好等優(yōu)點(diǎn)，它的出現(xiàn)也是為了解決 npm 和yarn 存在的問(wèn)題。

1.pnpm通過(guò)硬鏈接與符號(hào)鏈接結(jié)合的方式，來(lái)解決 yarn和 npm 的問(wèn)題。

• 硬鏈接：硬鏈接可以理解為源文件的副本，pnpm 會(huì)在全局 store 存儲(chǔ)項(xiàng)目 node_modules 文件的硬鏈接。硬鏈接可以使得不同的項(xiàng)目可以從全局 store 尋找到同一個(gè)依賴，大大節(jié)省了磁盤空間。
• 軟鏈接：軟鏈接可以理解為快捷方式，pnpm在引用依賴時(shí)通過(guò)符號(hào)鏈接去找到對(duì)應(yīng)磁盤目錄（.pnpm）下的依賴地址。

比如 A 依賴 B，A 下面是沒(méi)有 node_modules的，而是一個(gè)軟鏈接。實(shí)際真正的文件位于.pnpm 中對(duì)應(yīng)的 [email protected]/node_modules/A目錄并硬鏈接到全局 store 中。

而 B 的依賴存在于 .pnpm/[email protected]/node_modules/B。
而 A 依賴的 B，用軟鏈接鏈到上面的地址，也就是 B \--> ../../[email protected]/node_modules/B

node_modules
├──?A?-->?.pnpm/[email protected]/node_modules/A
└──?.pnpm
????├──[email protected]
????│????└──?node_modules
????│????????└──?B?==>??/B
????└──[email protected]
????????└──?node_modules
????????????├──?B?-->?../../[email protected]/node_modules/B
????????????└──?A?==>??/A
復(fù)制代碼

--> 代表軟鏈接，==》代表硬鏈接

而這種嵌套node_modules結(jié)構(gòu)的好處在于只有真正在依賴項(xiàng)中的包才能訪問(wèn)，很好地解決了幽靈依賴的問(wèn)題。此外，因?yàn)橐蕾囀冀K都是存在store目錄下的硬鏈接，相同的依賴始終只會(huì)被安裝一次，多重依賴的問(wèn)題也得到了解決。

2. 當(dāng)然 pnpm 也存在一些局限。

• pnpm-lock.yaml 和 package-lock.json 不一致，不能兼容。
• 一些場(chǎng)景不兼容，比如 Electron。
• 不同應(yīng)用的依賴是硬鏈接到同一份文件，所以不能直接修改依賴文件，否則會(huì)影響其他項(xiàng)目。而且因?yàn)榘惭b結(jié)構(gòu)不同，原來(lái)的 patch-package 之類的工具也不能用了。

雖然還有種種問(wèn)題，但總體來(lái)說(shuō)瑕不掩瑜。

其他

ni 可以理解為包管理器的管理器，ni?假設(shè)您使用鎖文件（并且您應(yīng)該），在它運(yùn)行之前，它會(huì)檢測(cè)你的 yarn.lock / pnpm-lock.yaml / package-lock.json 以了解當(dāng)前的包管理器，并運(yùn)行相應(yīng)的命令。

cnpm cnpm 和 npm 以及 yarn 之間最大的區(qū)別就在于生成的 node_modules 目錄結(jié)構(gòu)不同，這在某些場(chǎng)景下可能會(huì)引發(fā)一些問(wèn)題。此外也不會(huì)生成 lock 文件。但是 cnpm 保持了 node_modules 的目錄結(jié)構(gòu)清晰，可以說(shuō)是在嵌套模式和扁平模式之間找到了一個(gè)平衡。

很多面試會(huì)問(wèn) pnpm 為啥快，除了上面的store保證全局只安裝一次，還有軟連接保證不重復(fù)安裝之外。還有一個(gè)，當(dāng)安裝同一依賴的不同版本時(shí)，只有不同的部分會(huì)被重新保存。

建議不管用什么包管理工具，都要加上 lock 文件，在版本更新期間去升級(jí)依賴。以便能獲得更好的安全性。

esbuild

流行度：89%

esbuild 是一個(gè)用 go 語(yǔ)言寫的 javascript、typescript 打包工具，速度比 webpack 快 100 倍以上。

雖然打包工具用的各不相同，有 vite、webpack、Rollup，但最終都用到了 esbuild 打包。只有一個(gè)vuetify沒(méi)用，不過(guò)vuetify還沒(méi)有正式發(fā)布，后面也說(shuō)不定會(huì)換。

未來(lái) ESM 標(biāo)準(zhǔn)會(huì)越來(lái)越流行，所以相對(duì)應(yīng)的工具鏈也會(huì)越來(lái)越流行。

vite 嚴(yán)格來(lái)說(shuō)不是打包工具，而是一個(gè)前端構(gòu)建工具，vite 實(shí)際使用 Rollup 和 esbuild 打包。

SVG Icon

流行度：55%

關(guān)于Icon Font的缺陷，可以看這篇Inline SVG vs Icon Fonts^[13] 文章。主要有以下幾方面：

1. 瀏覽器將其視為文字進(jìn)行抗鋸齒優(yōu)化，有時(shí)得到的效果并沒(méi)有想象中那么銳利。尤其是在不同系統(tǒng)下對(duì)文字進(jìn)行抗鋸齒的算法不同，可能會(huì)導(dǎo)致顯示效果不同。
2. Icon Font 作為一種字體，Icon 顯示的大小和位置可能要受到font-size、line-height、word-spacing 等等 CSS 屬性的影響。Icon 所在容器的 CSS 樣式可能對(duì) Icon 的位置產(chǎn)生影響，調(diào)整起來(lái)很不方便。
3. 使用上存在不便。首先，加載一個(gè)包含數(shù)百圖標(biāo)的 Icon Font，卻只使用其中幾個(gè)圖標(biāo)，非常浪費(fèi)加載時(shí)間。自己制作 Icon Font 以及把多個(gè) Icon Font 中用到的圖標(biāo)整合成一個(gè) Font 也非常不方便。
4. 為了實(shí)現(xiàn)最大程度的瀏覽器支持，可能要提供至少四種不同類型的字體文件。包括TTF、WOFF、EOT?以及一個(gè)使用 SVG 格式定義的字體。
5. 網(wǎng)絡(luò)延時(shí)會(huì)導(dǎo)致 Icon 會(huì)先加載出來(lái)一個(gè) string。

SVG Icon 的優(yōu)勢(shì)可以用組件文檔的描述

1. 完全離線化使用，不需要從 CDN 下載字體文件，圖標(biāo)不會(huì)因?yàn)榫W(wǎng)絡(luò)問(wèn)題呈現(xiàn)方塊，也無(wú)需字體文件本地部署。
2. 在低端設(shè)備上 SVG 有更好的清晰度。
3. 支持多色圖標(biāo)。
4. 對(duì)于內(nèi)建圖標(biāo)的更換可以提供更多 API，而不需要進(jìn)行樣式覆蓋。

SVG Icon的劣勢(shì)，比如兼容性。（IE：啥？）

當(dāng)然總體來(lái)說(shuō)，Icon Font 對(duì)性能的影響沒(méi)有那么大。這也可能是沒(méi)那么流行的原因？

CSS變量

流行度：88%

雖然編寫還是使用的預(yù)處理語(yǔ)言，但是最后都想辦法轉(zhuǎn)成了 CSS var。就性能來(lái)說(shuō)，肯定是瀏覽器支持的 W3C 規(guī)范更好。

但是目前很多預(yù)處理語(yǔ)言的函數(shù)之類的功能，原生還不是很好的支持。所以預(yù)處理語(yǔ)言還很有存在的必要的。

好了，這就是本篇文章的全部?jī)?nèi)容了，感謝大家的觀看。

我是一個(gè)努力成長(zhǎng)的前端菜狗子。