依據最佳做法選取及設定建構工具。
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。