Bundled Engines

## What a "bundled engine" is Playwright does not automate the Chrome, Firefox or Safari already installed on your machine. Every Playwright release **pins a specific build** of three engines — Chromium, Firefox and WebKit — and `npx playwright install` downloads those builds onto the machine. The `playwright-core` package carries a `browsers.json` manifest naming a **revision** per engine, and at run time the library resolves a folder such as `chromium-1244` inside a cache directory. Bump the npm package and the expected revision moves with it, which is why an upgrade is normally followed by another `npx playwright install`. ## Why ship builds rather than drive what is installed - **Reproducibility.** Every developer and every machine runs the *same* engine binary, so a failure in the hotel-booking search results is a property of the code, not of whose laptop ran it. - **Patched engines.** The builds carry Playwright's own patches, which is what makes the automation protocol, the inspector and features such as tracing work uniformly across all three. - **Lead time.** The bundled builds run ahead of the browsers the public is on, so a change that will break the room-detail page surfaces weeks before users meet it. - **No install lottery.** Nothing on the machine has to be present, at a version, or on a `PATH`. ## The two identities people get wrong **Playwright's WebKit is not Safari.** It is built from recent WebKit sources with Playwright's patches applied, so it typically runs ahead of what Apple has shipped. Playwright cannot drive branded Safari at all, because the automation depends on those patches. WebKit is a good proxy for Safari's rendering and JavaScript behaviour, not a substitute for it — and platform-dependent behaviour such as media codec support differs between WebKit on Linux and WebKit on macOS, so the closest-to-Safari signal comes from running it on a Mac. **Playwright's Chromium is not your Chrome.** It is a separate download that never auto-updates, is untouched by the enterprise policies, extensions and proxy rules your corporate Chrome obeys, and sits at a different version. Since Playwright 1.57 the bundled Chromium is a *Chrome for Testing* build (headed mode runs `chrome`, headless runs `chrome-headless-shell`); on Arm64 Linux it remains a Chromium build. If you want the shipping product instead, that is the branded channel story, a deliberate opt-in — not the default. ## Where the builds land Downloads go into an OS-specific cache folder named `ms-playwright`, and each engine occupies a few hundred megabytes: | Platform | Default location | |---|---| | Linux | `~/.cache/ms-playwright` | | macOS | `~/Library/Caches/ms-playwright` | | Windows | `%USERPROFILE%\AppData\Local\ms-playwright` | Playwright tracks which installations still reference each build and deletes versions no client needs any more, so upgrading repeatedly does not silently fill the disk. ## What the model costs you 1. **An extra install step.** Adding the package is not enough; the engines are fetched by a separate command, and forgetting it produces `Executable doesn't exist at ...`, whose own message tells you to run `npx playwright install`. 2. **Disk and download time.** Three engines plus the headless shell are large. You can narrow this by naming engines — `npx playwright install chromium` — or by installing only the headless shell with `--only-shell` when nothing runs headed. 3. **A second thing to keep in step.** The package version and the on-disk builds must agree, which makes the install a normal part of the dependency-install routine rather than a one-off. ## Checking what you actually have `npx playwright install --list` prints the builds present across all Playwright installations on the machine, and `npx playwright install --dry-run` reports what the current version *would* download without touching anything. Both are the quickest way to answer "which engine did that run really use?" before you start blaming the hotel-booking application itself.