依據最佳做法選取及設定建構工具。
web.dev 如今要推出名為 tooling.report 的新計畫。您可運用這個網站，為網頁開發人員概略介紹一系列熱門建構工具支援的功能。我們建構這個協作平台的目的，是協助您為下一個專案選擇合適的建構工具、判斷是否值得從某一項工具遷移至另一項工具，或思考如何將最佳做法整合至您的工具設定和程式碼集。工具有不同的重點領域，且能滿足不同的需求；也就是說，在選取和設定工具時，必須做出取捨。我們希望透過 tooling.report 說明這些取捨，並記錄下任何特定建構工具如何遵循最佳做法。
聽起來很精彩嗎？請前往 toolsing.report 開始探索，或閱讀詳情，瞭解我們開發這個網站的原因和方式。
建構工具
我們在 GoogleChromeLabs 中建構了 Squoosh 和 Proxx 等網頁應用程式，以及 2019 年 Chrome 開發人員高峰會等網站。如同任何網路開發專案，我們通常會先討論專案基礎架構，例如託管環境、架構和建構工具設定。隨著專案進展，基礎架構會隨之更新：新增外掛程式是為了配合我們採用的架構或技術，或是編寫程式碼的方式改變，讓建構工具更瞭解我們想達成的目標。在這個過程中，我們經常發現所選的工具最終會妨礙使用體驗。
我們的團隊致力於為使用者提供最佳網路體驗，而這往往會導致前端資產的組合與提供方式出現微調。舉例來說，如果主要執行緒指令碼和網路工作站指令碼具有共用的依附元件，我們想要下載一次依附元件，而非針對每個指令碼組合兩次。有些工具預設支援這項功能，有些工具需要大量自訂作業來變更預設行為，而對其他工具則並非如此。
因此，我們憑藉著這項經驗，研究不同建構工具可執行哪些功能，希望建立功能檢查清單，方便下次建立新專案時評估及選擇最適合專案的工具。
我們的做法
我們該如何在單一位置評估及比較各種建構工具？我們寫了測試案例
我們的團隊討論並設計測試標準，評估出網站開發最佳做法。我們特別著重於如何提供快速、回應和流暢的使用者體驗，並刻意排除與開發人員體驗相關的測試，以免評估兩種無法比較的結果。
建立測試清單後，我們會為每項工具編寫建構指令碼，確認工具能否達到測試的成功條件。首先，我們決定調查 Webpack v4、Rollup v2 和 Parcel v2。此外，我們也測試了 Browserify + Gulp，因為許多專案仍在使用這項設定。為了通過測試，只能使用工具的公開記錄功能或工具外掛程式。編寫初始測試後，我們與建構工具作者合作，確保我們正確使用他們的工具，並以公平的方式呈現。
我們只使用「${tool_name}」，要我繼續保持嗎？
在許多團隊中，會負責維護建構基礎架構的人員，而其他團隊成員可能從未在建構工具時做出選擇。希望這個網站也能對您有幫助，讓您瞭解常用的工具。我們針對每項測試加入了說明，說明測試的重要性並提供其他資源。此外，如果您想針對所選工具採用最佳做法，存放區中的測試設定會包含進行此操作所需的設定檔。
我可以為網站貢獻內容嗎？
如果您認為目前找不到的特定功能需要測試，請在 GitHub 問題中提議，以展開討論。我們的目標是封裝實際的應用實例，並歡迎任何進一步評估這些結果的測試。
如果您想為初始設定未納入的工具編寫測試，我們也歡迎你這麼做！ 詳情請參閱 CONTRIBUTING.md。