組件庫設計主要考慮幾點。
有意義：

• 命名準確，充分表意。
• 參數準確，必要的類型檢查。
• 適當的注釋
  通用性：
• 不要耦合特殊的業務功能。
• 不要包含特定的代碼處理邏輯。
  ?狀態，?副作?：
• 狀態向上層提取，盡量少?內部狀態。
• 解耦IO操作。
  避免過度封裝：
• 合理冗余。
• 避免過度抽象。
  單一職責：
• ?個組件只完成?個功能。
• 盡量避免不同組件?相互依賴、循環依賴。
  易于測試：
  更容易的單元測試覆蓋。

組件庫設計主要有幾大模塊。

一、組件庫架構選擇----倉庫管理

Multirepo
?個倉庫內只?個項?，以?個npm包發布，適?于基礎組件庫。
優點

• 項?簡單，調試安裝?較?便。
  缺點
• 項?龐?時構建和發布耗時?。
• 組件庫使?時需整體引?，造成?定的資源浪費。（可通過es module?式解決）
  比如：antdsign

管理工具
git submodule
（git提供的一種管理子倉庫的方案
可以批量管理和維護多個git repo
本質上是一個父repo維護了一份各個子repo 的清單
有坑: Git Submodule的坑
替代方案: git subtree

Monorepo
?個倉庫內管理多個項?，以多個npm包?式發布，依賴集中管理，npm包版本可以集中管理，也可以 單獨管理。通常適?于有?定關聯的組件，但各組件需要?持單獨的npm包發布和安裝。
優點：

• 共同依賴統?管理，版本控制更加容易，依賴管理會變的?便。
• ?持組件的單獨發布和單獨構建。
• 使?時可以單獨引?。
  缺點：
• 項?搭建復雜度?。
  比如react

管理工具：

• lerna
• yarn workspace
• pnpm

二、代碼規范

?個?質量的組件庫，eslint和prettier是必須的，能夠幫助我們統?整個倉庫的代碼規范。 常?的eslint配置：

"eslint:recommended",
"plugin:react/recommended",
"plugin:react-hooks/recommended",
// 如果使?ts
"plugin:@typescript-eslint/eslint-recommended",
"plugin:@typescript-eslint/recommended",
"prettier"

也可以使?業界成熟的eslint配置: @umijs/fabric
.eslintrc.js

module.exports = {extends: [require.resolve('@umijs/fabric/dist/eslint')],
};

.stylelintrc.js

module.exports = {extends: [require.resolve('@umijs/fabric/dist/stylelint')],
};

.prettierrc.js

const fabric = require('@umijs/fabric');
module<