不少人都曾經在 npm 上發布過自己開發的 JavaScript 模組，而在使用一些模組的過程中，我經常產生「這個模組很有用，但如果能 xxx 就更好了」的想法。所以，本文將站在模組使用者的角度總結一下，如何能讓模組變得更好用。本文主要和分享如何才能開發出更好的JavaScript模組和功能，希望能幫助大家。
提供ES6 模組的入口
webpack 和rollup 都支援對ES6 模組做一些靜態最佳化（例如Tree Shaking 和Scope Hoisting），它們都會優先讀取package .json 中的module 欄位作為ES6 模組的入口，若沒有module 才會讀取main 欄位作為CommonJS 模組的入口。通常的做法是：使用 ES6 語法編寫原始碼，然後用模組打包工具結合語法轉換工具產生 CommonJS 模組和 ES6 模組，這樣就可以同時提供 main 和 module 欄位了。
提供TypeScript 的類型聲明文件
如果你的用戶使用了TypeScript 但你的模組沒有提供聲明文件，他們就必須在專案中加入一段程式碼避免TypeScript 的編譯錯誤；另外，這樣做並不只是對使用TypeScript 的用戶友好，因為大部分程式碼編輯器（Webstorm、VS Code 等）都能識別TypeScript 的類型聲明，它們可以據此提供更精準的程式碼提示並在使用者傳入錯誤的參數個數或類型時給予提示。
最好的做法是使用 TypeScript 寫你的模組，編譯時會自動產生型別宣告。除此之外，你也可以參考文件手動維護一份聲明文件。你可以在你的模組根目錄下新增 index.d.ts 文件，或是在 package.json 中聲明 typings 欄位提供聲明文件的位置。
讓模組同時在Node.js 與瀏覽器中執行
你可以透過偵測是否有名為window 的全域變數（例如!!typeof window）來判斷模組目前是執行在Node .js 還是瀏覽器中，然後使用不同的方式實作你的功能。
這種方法比較常見，但如果使用者使用了模組打包工具，這樣做會導致 Node.js 與瀏覽器的實作方式都會被包含在最終的輸出檔案中。針對這個問題，開源社群提出了在 package.json 中加入 browser 欄位的提議，目前 webpack 和 rollup 都已經支援這個欄位了。
browser 欄位有兩種使用方式：
給browser 欄位提供一個檔案路徑作為在瀏覽器端使用時的模組入口，但需要注意的是，打包工具會優先使用browser 欄位指定的檔案路徑作為模組入口，所以你的module 欄位會被忽略，這會導致打包工具不會最佳化你的程式碼。詳細資訊請參考這個問題。
如果你只想替換其中一些文件，你可以聲明一個物件。
舉個例子，假設你的模組裡有兩個檔案：http.js 和xhr.js，第一個檔案使用Node.js 中的http 模組發起請求，另一個使用瀏覽器中的XMLHTTPRequest 實作了同樣的功能。為了使用適當的文件，你的模組程式碼應該始終require('./path/to/http.js')，並在package.json 中聲明：
{
"browser": {
"./path/to/http.js": "./path/to/xhr.js"
}
}這樣一來，當你的模組在打包工具中使用時，打包工具只會將xhr.js 的程式碼包含在最終的輸出檔中。
使用各種服務來武裝你的專案
大部分JavaScript 專案都是開源的，而開源社群也提供了許多針對開源專案的免費服務，它們可以為你的專案提供更有力的幫助，這裡列舉幾個比較常用的。
一個專案最常使用的服務就是持續整合了。持續整合服務能將測試、程式碼風格偵測、打包等任務放在伺服器上，並在你提交程式碼時自動執行，常用的有 Travis CI、CircleCI 和 AppVeyor。 Travis CI 對開源專案免費，提供 Linux 與 OS X 運行環境；CircleCI 對開源與私有專案都免費，但每個月有 1500 分鐘的運行時間限制；AppVeyor 提供 Windows 運行環境，同樣對開源專案免費。
執行完測試之後，你也可以將測試覆蓋率上傳到 Coveralls。這個服務能讓你在線上瀏覽程式碼的測試覆蓋情況。
如果你想讓你的模組在各個版本的各種瀏覽器、平台下得到充分的測試，你還可以使用Sauce Labs 和BrowserStack，它們都是對開源專案免費的，但需要發郵件申請。
最後，Shields IO 提供了各種圖標，這些圖標能為你的項目提供很多額外信息，包括但不限於npm 版本號、下載量、測試通過狀態、測試覆蓋率、文件大小、依賴是否過期等。
相關推薦：
以上是實例講解開發更好的JavaScript模組的詳細內容。更多資訊請關注PHP中文網其他相關文章！
