使用 tooling.report 为您的项目选择最佳构建工具

根据最佳实践选择和配置构建工具。

今天,web.dev 将推出一项名为 tooling.report 的新计划。该网站可让 Web 开发者大致了解一系列常用构建工具支持的功能。我们构建此网站是为了帮助您为下一个项目选择合适的构建工具、确定从一个工具迁移到另一个工具是否值得,或者思考如何将最佳实践整合到工具配置和代码库中。工具有不同的侧重点,并且满足不同的需求组合,这意味着在选择和配置工具时,您需要做出权衡取舍。我们通过 tooling.report 说明这些权衡因素,并记录如何使用任何给定构建工具遵循最佳实践。

听起来很有趣?请访问 tooling.report 开始探索,或继续阅读,详细了解我们开发此网站的原因和方式。

构建工具经常会妨碍我们

GoogleChromeLabs 上,我们构建了 SquooshProxx 等 Web 应用,以及 2019 年 Chrome 开发者峰会等网站。与任何 Web 开发项目一样,我们通常首先会讨论项目基础架构,如托管环境、框架和构建工具设置。该基础架构会随着项目的进度而更新:我们会添加新的插件以适应我们采用的框架或技术;或者改变代码编写方式,让我们的构建工具能够更好地了解我们想要实现的目标。在这个过程中,我们经常发现我们选择的工具最终妨碍了我们。

我们的团队专注于为用户提供出色的 Web 体验,这通常可以对前端资源的组合和交付方式进行微调。例如,如果主线程脚本和 Web 工作器脚本具有共享依赖项,我们希望将依赖项下载一次,而不是为每个脚本绑定两次。有些工具支持开箱即用型功能,有些工具需要进行大量自定义工作才能更改默认行为,而有些工具则完全不可能。

这次经验引领我们研究了不同构建工具可以用和不可以用什么。我们希望为功能创建一份核对清单,以便下次开始一个新项目时,我们可以评估并选择最适合我们项目的工具。

我们的做法

如何在同一个位置评估和比较不同的构建工具?为此,我们编写了测试用例。

我们的团队讨论并制定了我们认为能够代表 Web 开发最佳实践的测试标准。我们特别专注于如何提供快速、响应迅速且流畅的用户体验,有意排除与开发者体验相关的测试,以避免衡量两种不可比较的结果。

创建测试列表后,我们继续为每种工具编写了 build 脚本,以检查相应工具是否符合测试的成功标准。最初,我们决定研究 webpack v4、Rollup v2 和 Parcel v2。由于许多项目仍在使用此设置,我们还测试了 Browserify + Gulp,要想通过测试,只能使用该工具或该工具的插件的公开记录功能。编写了首批测试后,我们与构建工具的作者合作,以确保正确使用他们的工具并公平地呈现它们。

Tooling.report 的屏幕截图。

我们只使用 ${tool_name},我还应该在意吗?

在许多团队中,都有人致力于维护构建基础架构,团队的其他成员可能永远无法在构建工具方面做出选择。我们希望这个网站依然能对您有所帮助,帮助您建立起对所依赖工具的预期。对于每项测试,我们都说明了该测试的重要性,并提供了其他资源。如果您想采用自己选择的工具并采用最佳实践,我们代码库中的测试设置包含执行此操作所需的配置文件。

我可以为网站做贡献吗?

如果您认为应测试的某项功能目前缺失,请在 GitHub 问题中提出相应功能以开始讨论。我们的目标是封装真实用例,欢迎进行任何其他能够更好地评估这些结果的测试。

如果您想要为我们在初始集中未包含的工具编写测试,我们也欢迎您这样做! 如需了解详情,请参阅 CONTRIBUTING.md