Picking a build tool without guesswork
Build tooling choices usually come down to habit, hype, or whatever configuration a project was started with. The trade-offs between tools — what each one handles natively, what needs custom plugins, and what is effectively impossible — rarely get a clear, side-by-side comparison. A new site from the team behind Squoosh and Proxx aims to fix that.
tooling.report documents which features a selection of popular build tools support, and how to configure them according to best practices. It's designed for three use cases: choosing a tool for a new project, evaluating whether a migration from one tool to another is worth the effort, and bringing an existing setup in line with recommended patterns.
Testing tool behavior, not opinions
The project grew out of the GoogleChromeLabs team's own experience building web apps and event sites. A recurring problem: the code they wanted to write and the way they wanted to ship assets didn't always match what their build tool allowed. A typical example is shared dependencies between a main thread script and a web worker — ideally that code is downloaded once, not duplicated in both bundles. Some tools do this by default, some require deep configuration changes, and some can't do it at all.
To compare tools on a level field, the team wrote test cases. Each test represents a practice they consider important for delivering fast, responsive user experiences. Developer experience criteria were deliberately left out, since those are harder to measure objectively. Each test has a success criterion and a build script for every tool under evaluation. For a test to pass, the tool or one of its plugins only needs a publicly documented way to achieve the result.
Coverage and verification
The initial tool set covers webpack v4, Rollup v2, and Parcel v2, plus the still-common Browserify + Gulp combination. After writing the first version of every test, the team worked with the respective build tool maintainers to ensure the tools were being used correctly and results were fair.
Useful even if you're not choosing
Not everyone gets a say in build tool selection. Many developers inherit an infrastructure that someone else set up, and switching is not on the table. The site still has value in that situation: every test includes an explanation of why the practice matters and links to additional resources, so you know what your tool is — or isn't — doing for you. If you want to adopt a best practice, the test repository contains the exact configuration files used, which you can adapt for your own project.
Contributing new tests and tools
The test set is not meant to be static. If a feature you care about isn't covered, you can start a discussion by filing a GitHub issue. The team wants the tests to reflect real-world use cases, so proposals that better capture those scenarios are welcome. Contributions of tests for tools outside the initial four are also accepted; the CONTRIBUTING.md file in the repository explains how to get started.
