進行這樣的編譯時，請確保同時也創(chuàng)建 sourcemap

記錄更新和變更。

只要能讓開發(fā)者了解到有哪些變更和對他們的影響，至于是通過自動化工具還是通過親自動手的方式來處理，這都無關緊要。理想情況下，庫的每次版本變更都應該在 changelog 中進行相應的更新。

讓開發(fā)者能夠按需引入 CSS。

如果你正在創(chuàng)建一個 CSS 庫（如 Bootstrap、Tailwind 等），最簡單的方式就是提供單一文件，包含庫的所有功能。然而，在這種情況下，你的 CSS 產(chǎn)出最終可能會變得很大，影響開發(fā)者網(wǎng)站的性能。為了避免這種情況，庫通常會提供自定義生成 CSS 產(chǎn)出的功能，讓產(chǎn)出中只包含開發(fā)者正在使用的必要 CSS（例如，參考 Bootstrap 和 Tailwind 是怎么做的）。

如果 CSS 只是你的庫的一部分（例如，具有默認樣式的組件庫），那么最好將 CSS 按組件分離單獨構建產(chǎn)出，在使用相應的組件時按需導入。這方面的一個例子是 react-component。

package.json中有許多重要的配置字段值得討論；我在這里將著重討論其中最為重要的一些，這還有很多額外的字段，你同樣可以進行配置。

給你的庫取一個名：

name?字段將決定你的包在npm上的名字，開發(fā)者可以通過這個名字去安裝并使用你的庫。

注意，庫的命名是有限制的，如果你的代碼庫屬于某個組織，你還可以創(chuàng)建一個命名空間。更多細節(jié)可以參考 name docs on npm。

name和 version 的組合為庫每次迭代創(chuàng)建一個唯一標識。

通過更改 version 來對你的庫發(fā)布更新：

正如 name 部分所說，name?和version?的組合為你的庫在 npm 上創(chuàng)建一個唯一標識。當你更新庫中的代碼時，你可以更新version字段并發(fā)布以允許開發(fā)者獲取該新代碼。

推薦使用 semver 版本控制策略，但要注意的是有些庫選擇 calver 或使用他們自己特有的版本控制策略。無論你選擇使用哪種策略，都應該記錄下來，以便開發(fā)者了解你的庫是如何進行版本控制的。

你還應該在 changelog 中記錄你的更改。

exports 為你的庫定義公共 API：

package.json?中的exports字段 - 有時被稱為“package exports” - 是一個非常有用的補充，盡管它確實引入了一些復雜性。它做的最重要的兩件事是：

關于這部分的內(nèi)容NodeJS 團隊和Webpack 團隊提供了一些很優(yōu)秀的文檔。在此我列出一個涵蓋大部分常見場景的例子：

{  "exports": {    ".": {      "types": "index.d.ts",      "module": "index.js",      "import": "index.js",      "require": "index.cjs",      "default": "index.js"    },    "./package.json": "./package.json"  }}

讓我們深入了解這些字段的含義以及我選擇這個例子的原因：

當一個打包工具或者運行時支持exports?字段的時候，那么package.json?中的頂級字段 main、types、module 還有 browser 將被忽略，被exports?取代。但是，對于尚不支持exports字段的工具或運行時來說，設置這些字段仍然很重要。

如果你有一個 "development" 和一個 "production" 的產(chǎn)出（例如，你有一些警告在 development 產(chǎn)出中有但在 production 產(chǎn)出中沒有），那么你可以通過在exports?字段中"development"?和"production"?來設置它們。注意一些打包工具例如webpack?和vite將會自動識別這些導出條件，而 Rollup 也可以通過配置來識別它們，你需要提醒開發(fā)者在他們自己打包工具的配置中去做這些事。

files定義你的 NPM 包中要包含哪些文件：

files?決定npmCLI 在打包庫時哪些文件和目錄包含到最終的 NPM 包中。

例如，如果你將代碼從 TypeScript 編譯為 JavaScript，你可能就不想在 NPM 包中包含 TypeScript 的源代碼。（相反，你應該包含 sourcemap）。

files可以接受一個字符串數(shù)組（如果需要，這些字符串可以包含類似 glob 的語法），例如：

{  "files": ["dist"]}

注意，文件數(shù)組不接受相對路徑表示；"files": ["./dist"]將無法正常工作。

驗證你已正確設置files?的一種好方法是運行npm publish --dry-run，它將根據(jù)此設置列出將會包含的文件。

type?規(guī)定你的.js文件使用哪個模塊系統(tǒng)：

運行時和打包工具需要一種方法來確定你的.js?文件采用哪種模塊系統(tǒng) —— ESM 還是 CommonJS。因為 CommonJS 首先出現(xiàn)，所以它被打包工具視為默認的 - 但你可以通過在你的package.json?中添加"type"來控制這種行為。

你可以選擇"type":"module"?或"type":"commonjs"，也可以不添加該字段（默認為 CommonJS），但仍強烈建議你進行設置，顯式地聲明你正在使用哪一個。

請注意，你可以通過幾個技巧在項目中混用模塊類型：

設置sideEffects來允許 treeshaking：

創(chuàng)建一個“純模塊”帶來的優(yōu)點與創(chuàng)建一個純函數(shù)十分類似；打包工具能夠對你的庫更好的進行 treeshaking。

通過設置sideEffects讓打包工具知道你的模塊是否是“純”的。不設置這個字段，打包工具將不得不假設你「所有」的模塊都是有副作用。

sideEffects?可以設為false，表示沒有任何模塊具有副作用，也可以設置為字符串數(shù)組來列出哪些文件具有副作用。例如：

{  // 所有模塊都是“純”的  "sideEffects": false}

或：

{  // 除了 "module.js"，所有模塊都是“純”的  "sideEffects": ["module.js"]}

所以，什么讓一個模塊具有副作用？例如修改一個全局變量，發(fā)送 API 請求，或導出 CSS，而且開發(fā)人員不需要做任何事情這些動作就會被執(zhí)行。例如：

// 具有副作用的模塊export const myVar = "hello";window.example = "testing";

導入myVar?時，你的模塊自動設置window.example。

例如：

import { myVar } from "library";console.log(window.example);// 打印 "testing"

在某些情況下，如 polyfill，這種行為是有意的。然而，如果我們想讓這個模塊是“純”的，我們可以將對window.example的賦值移動到一個函數(shù)中。例如：

// 一個“純”模塊export const myVar = "hello";export function setExample() {  window.example = "testing";}

現(xiàn)在這是一個“純”模塊。注意，從開發(fā)者的角度來看會有不同：

import { myVar, setExample } from "library";console.log(window.example);// 打印 "undefined"setExample();console.log(window.example);// 打印 "testing"

main定義 CommonJS 入口：

main?是一個當打包工具或運行時不支持package.json#exports?時的兜底方案；如果打包工具或運行時支持 package exports，則不會使用main。

main?應該指向一個兼容 CommonJS 格式的產(chǎn)出；它應該與 package exports 中的require保持一致。

module定義 ESM 入口：

module?是一個當打包工具或運行時不支持package.json#exports?時的兜底方案；如果打包工具或運行時支持 package exports，則不會使用module。

module?應該指向一個兼容 ESM 格式的產(chǎn)出；它應該與 package exports 中的module?或import保持一致。

支持 CDN，例如unpkg?和jsdelivr：

為讓你的庫在 CDN 上“以默認的方式正常工作”，如 unpkg 和 jsdelivr，你可以設置它們的特定字段指向你的umd產(chǎn)出。例如：

{  "unpkg": "./dist/index.umd.js",  "jsdelivr": "./dist/index.umd.js"}

browser指向能在瀏覽器中工作的產(chǎn)出：

browser?是一個當打包工具或運行時不支持package.json#exports?時的兜底方案；如果打包工具或運行時支持 package exports， 則不會使用browser。

browser?應該指向能在瀏覽器中工作的esm?產(chǎn)出。但是，只有在為瀏覽器和服務器（等其他非瀏覽器環(huán)境）創(chuàng)建不同的產(chǎn)出時，才需要設置該字段。如果你沒有為多個環(huán)境創(chuàng)建多個產(chǎn)出，或者你的產(chǎn)出是“純 JavaScript”或“通用”的，可以在任何 JavaScript 環(huán)境中運行，那么你就不需要設置browser字段。

如果你確實需要設置該字段，這里有一個優(yōu)秀的指南，介紹了配置它的不同方法。

注意，browser?字段不應該指向umd產(chǎn)出，因為那樣的話，你的庫就不會被打包工具（如 Webpack）進行 treeshaking，這些打包工具會優(yōu)先考慮這個字段，而不是其他字段，比如 module 和 main。

types定義 TypeScript 類型：

types?是一個當打包工具或運行時不支持package.json#exports?時的兜底方案；如果打包工具或運行時支持 package exports，則不會使用types。

types?應該指向你的 TypeScript 入口文件，例如index.d.ts?；它應該與 package exports 中的types字段指向同一個文件。

如果你依賴別的框架或庫，將它設置為 peer dependency：

你應該外置框架。然而，這樣做后，你的庫只有在開發(fā)人員自行安裝你需要的框架后才能工作。設置peerDependencies讓他們知道他們需要安裝的框架。- 例如，如果你在創(chuàng)建一個 React 庫：

{  "peerDependencies": {    "react": "^18.2.0",    "react-dom": "^18.2.0"  }}

你應該以書面形式來體現(xiàn)這些依賴；例如，npm v3-v6?不安裝 peer dependencies，而npm v7+將自動安裝 peer dependencies。

保護你自己和其他的貢獻者：

開源許可證用于保護貢獻者和用戶。沒有這種保護，企業(yè)和有經(jīng)驗的開發(fā)者不會使用該項目。

上述引用自 Choose a License，這也是一篇很好的文章，幫助你來決定哪個許可證適合你的項目。

當你決定了許可證，關于許可證的 npm 文檔中描述了許可證字段的格式。例如：

{  "license": "MIT"}

除此之外，你可以在項目的根目錄下創(chuàng)建一個LICENSE.txt文件，并將許可證的文本復制到這里。

關鍵詞： 壓縮工具 版本控制 開發(fā)人員 深入了解