根据最佳实践选择和配置构建工具。
今天，web.dev 将推出一项名为 tooling.report 的新计划。该网站可让 Web 开发者大致了解一系列常用构建工具支持的功能。我们构建此网站是为了帮助您为下一个项目选择合适的构建工具、确定从一个工具迁移到另一个工具是否值得，或者思考如何将最佳实践整合到工具配置和代码库中。工具有不同的侧重点，并且满足不同的需求组合，这意味着在选择和配置工具时，您需要做出权衡取舍。我们通过 tooling.report 说明这些权衡因素，并记录如何使用任何给定构建工具遵循最佳实践。
听起来很有趣？请访问 tooling.report 开始探索，或继续阅读，详细了解我们开发此网站的原因和方式。
构建工具经常会妨碍我们
在 GoogleChromeLabs 上，我们构建了 Squoosh 和 Proxx 等 Web 应用，以及 2019 年 Chrome 开发者峰会等网站。与任何 Web 开发项目一样，我们通常首先会讨论项目基础架构，如托管环境、框架和构建工具设置。该基础架构会随着项目的进度而更新：我们会添加新的插件以适应我们采用的框架或技术；或者改变代码编写方式，让我们的构建工具能够更好地了解我们想要实现的目标。在这个过程中，我们经常发现我们选择的工具最终妨碍了我们。
我们的团队专注于为用户提供出色的 Web 体验，这通常可以对前端资源的组合和交付方式进行微调。例如，如果主线程脚本和 Web 工作器脚本具有共享依赖项，我们希望将依赖项下载一次，而不是为每个脚本绑定两次。有些工具支持开箱即用型功能，有些工具需要进行大量自定义工作才能更改默认行为，而有些工具则完全不可能。
这次经验引领我们研究了不同构建工具可以用和不可以用什么。我们希望为功能创建一份核对清单，以便下次开始一个新项目时，我们可以评估并选择最适合我们项目的工具。
我们的做法
如何在同一个位置评估和比较不同的构建工具？为此，我们编写了测试用例。
我们的团队讨论并制定了我们认为能够代表 Web 开发最佳实践的测试标准。我们特别专注于如何提供快速、响应迅速且流畅的用户体验，有意排除与开发者体验相关的测试，以避免衡量两种不可比较的结果。
创建测试列表后，我们继续为每种工具编写了 build 脚本，以检查相应工具是否符合测试的成功标准。最初，我们决定研究 webpack v4、Rollup v2 和 Parcel v2。由于许多项目仍在使用此设置，我们还测试了 Browserify + Gulp，要想通过测试，只能使用该工具或该工具的插件的公开记录功能。编写了首批测试后，我们与构建工具的作者合作，以确保正确使用他们的工具并公平地呈现它们。
我们只使用 ${tool_name}，我还应该在意吗？
在许多团队中，都有人致力于维护构建基础架构，团队的其他成员可能永远无法在构建工具方面做出选择。我们希望这个网站依然能对您有所帮助，帮助您建立起对所依赖工具的预期。对于每项测试，我们都说明了该测试的重要性，并提供了其他资源。如果您想采用自己选择的工具并采用最佳实践，我们代码库中的测试设置包含执行此操作所需的配置文件。
我可以为网站做贡献吗？
如果您认为应测试的某项功能目前缺失，请在 GitHub 问题中提出相应功能以开始讨论。我们的目标是封装真实用例，欢迎进行任何其他能够更好地评估这些结果的测试。
如果您想要为我们在初始集中未包含的工具编写测试，我们也欢迎您这样做！ 如需了解详情，请参阅 CONTRIBUTING.md。