How would you weigh Playwright's bundled Chromium against a branded chrome or msedge channel for a booking suite?

## The two things you are choosing between The **bundled build** is the engine Playwright downloads for you: pinned to the Playwright version, fetched by `npx playwright install`, stored in the `ms-playwright` cache, and never updated except when you upgrade the package. Since Playwright 1.57 that Chromium is a *Chrome for Testing* build — headed runs use `chrome`, headless runs use `chrome-headless-shell` — while Arm64 Linux stays on Chromium. The **branded channel** is the shipping product on the machine: Google Chrome or Microsoft Edge, selected by name (`chrome`, `msedge`, and their `-beta`, `-dev` and `-canary` variants). Playwright does not install these by default. `npx playwright install msedge` will install one, but it lands at the operating system's normal global location and overrides the existing browser install there — which is a real consideration on a machine somebody also uses for browsing. Note the question this decides: **which build of the same engine family runs**, not how wide your engine matrix should be. ## How they compare | | Bundled build | Branded channel | |---|---|---| | Version control | pinned to the Playwright version | whatever is installed, auto-updating | | Provenance | downloaded by Playwright | the machine's own browser | | Relative to stable | ahead of it | is it | | Enterprise policy | unaffected | fully subject to it | | Reproducible across machines | yes | only if you manage the estate | ## What each one buys - **The bundled build buys determinism.** Two machines on the same lockfile run the same bytes. A failure in the room-search results is about your code, and a change in behaviour is traceable to a Playwright upgrade you can point at in the history. - **It also buys lead time.** Because Playwright runs ahead of the stable channels, a rendering or API change that will reach customers in a few weeks breaks your booking suite now, while there is time to react. - **The branded channel buys fidelity to the shipping product** — the exact build a guest uses, with its proprietary media codecs and its product-specific behaviour. That matters when the feature under test depends on something only the branded build carries. - **The branded channel also inherits enterprise policy**, which is usually a cost rather than a benefit: mandatory extensions, forced proxies and capability restrictions all sit between your test and the application, and they differ from one employee's laptop to the next. ## How to decide 1. **Default to the bundled build.** It is reproducible, it is ahead of the world, and it needs no estate management. 2. **Add a branded channel for the narrow slice that needs it** — the video or DRM path on the room gallery, or a defect that only reproduces in the shipping product. Keep it a small, explicitly justified part of the run, not the baseline. 3. **Never let an auto-updating channel be your only signal.** A browser that silently moves under you turns any change in results into a two-variable problem, and it makes a green run yesterday and a red run today unexplainable from your own history. 4. **Write down which build is authoritative** for reproducing a reported failure, so nobody debugs a customer report against a different engine than the one that produced it. ## The drift argument, stated plainly Pinning moves the update from *whenever the vendor ships* to *whenever you upgrade*. It does not remove browser change from your life; it schedules it. A team that pins engines gets one noisy afternoon per upgrade and quiet weeks in between; a team on auto-updating channels gets a small, unattributable chance of new failure every day. The first is a cost you can plan; the second is a tax on every investigation.