我的任務是開發一個帶有自定義組件（在本例中為 react 組件）的 NPM 包，該組件使用其他依賴項，例如 plate、slate 等。
我正在準備輸出dist，但我不清楚這樣做的最佳實踐是什么：是否應該解決所有依賴項并將其捆綁到一個大的 .js 檔案中，還是可以忽略它？（我在這里使用匯總決議）。恐怕這會產生一個巨大的檔案，包括所有依賴項的來源，但正如我所說，我真的不熟悉這個程序......
另一方面，不解決這種依賴關系并讓組件的最終消費者這樣做是常見的嗎？（我這里只是假設）
uj5u.com熱心網友回復：
這都是關于利弊......以及什么是可能的。例如，React 本身只能存在于整個專案的一個版本中，所以你永遠不應該包含它。
需要但未包含的依賴項應該像peerDependencies您一樣添加，package.json并且消費者有責任下載它們。包含依賴項的缺點（如dependencies以便消費者自動下載它們）是消費者的捆綁包可能比它需要的更大。在這里你應該考慮誰會消費它；它是供您組織內部使用還是公共使用？您對將在其中使用的背景關系有任何了解嗎？最好不要包含依賴項，因為它會為消費者提供更小的結果包，但如果依賴項的依賴項不太可能出現在消費者的構建環境中，您不妨將其添加到您的包中。您要避免的情況是您的包包含消費者已經在使用的同一包的不同版本；那么生成的包可能包含大量代碼的兩個版本，這些代碼可能會縮減為一個版本（如果消費者和您的包使用的版本兼容）。當然，與小的不常見依賴項相比，大型公共依賴項的所有這些都可能變得更糟，更有可能發生。
一個例子：在我的組織中，我們使用 Material-UI。我們有一個使用 Material-UI 的 React 組件包，我們在其他專案中使用它。由于 Material-UI 將始終存在于專案中，因此將其包含在包中是不好的做法，即使消費者（我們）有更高的責任將包的不同版本與任何版本的 Material-UI 對齊我們在適用專案中使用的。考慮到另一種消費環境，將其包含在包裝中可能更有意義。
根據我的說法，你永遠不應該捆綁你的包裹，因為它會使搖樹對消費者來說更加復雜。這適用于 esm 包（cjs 不可搖樹）。另一方面，在 cjs 中，捆綁包是毀滅性的，因為它阻止消費者進行更具體的匯入以避免匯入大量未使用的代碼，例如
import Comp from "package/Component"
代替
import { Comp } from "package"
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/435502.html
標籤：javascript npm 捆 卷起 npm-发布
上一篇：無法創建反應專案