Playwright 1.65 Adds Bun Support and Failure-Focused Reports

Playwright 1.65 was released on November 5. As Habr reports, the release adds the ability to run tests with Bun, compact reports, and a way to run individual tests without other tests running alongside them. It also changes how existing tests behave: before upgrading, teams should check what their test scenarios rely on.

Bun, reports, and tests without neighbors

Playwright Test runs with Bun using bunx --bun playwright test. The --bun flag is required: bunx playwright test still uses Node.js. When run this way, Bun transforms TypeScript into JavaScript itself, without Babel or Playwright’s compilation cache.

The runner is tested with Bun 1.4.3 on Linux. For now, UI mode does not rerun tests when files change, and --only-changed does not account for dependencies introduced through imports. When running with Bun, the --tsconfig option and JSX settings in tsconfig.json have no effect on tests; custom ESM loaders are not supported. Error stacks lack async frames, API names appear without their class names, and test console output does not appear in traces or UI mode. Changing the test command is easy; discovering later that familiar debugging details are missing is harder.

The new failures reporter is enabled with npx playwright test --reporter=failures. During a run, it shows failures and successful retries, then provides a summary at the end, but it does not report the progress of every test. HTML, JSON, and JUnit reports now have an onlyFailures option: they retain tests with unexpected results, including unexpected passes, flaky tests, and interrupted tests. If a test passes after failing, details of every attempt are preserved.

The built-in -exclusive- lock lets you run a selected test without other tests running in parallel. Playwright waits for the others to finish, starts no new tests while that test runs, then returns to normal parallel execution. This is useful when restarting a server or measuring performance: one sensitive scenario no longer means queuing the entire suite.

What could change in existing tests

In TypeScript projects, the useDefineForClassFields option in tsconfig.json matters: Playwright now respects it the same way the TypeScript compiler does. It is enabled by default when the compilation target is ES2022 or newer, or when no target is specified. If a class field uses a property declared in the constructor parameters, the field may be initialized before that property is assigned, causing a TypeError. You can fix this by moving initialization into the constructor or setting "useDefineForClassFields": false.

The locator.click(), check(), tap(), fill(), clear(), and selectOption() methods now wait until an element is no longer inert. If the attribute remains on the element or a parent container, the operation will time out. When tests are split into shards, finding no tests across all shards now produces No tests found; if an empty result is acceptable, there is --pass-with-no-tests. An individual empty shard is not treated as an error when other shards contain tests.

Cookie matching against URLs has changed to follow RFC 6265. Cookies for a specific host are no longer returned for its subdomains, and the path /api does not match /apiv2. Credentials in the proxy setting are used only for the proxy server; HTTP authentication on the site requires httpCredentials. In addition, text the browser does not render no longer contributes to accessible names or ARIA snapshots. Results from page.getByRole() and ARIA snapshot assertions may change.

You can now set a directory for the cache of transformed test files with PLAYWRIGHT_TRANSFORM_CACHE_DIR, and pass timeout and signal to cdpSession.send(). Playwright is no longer tested on Node.js 20: its developers recommend versions 22, 24, or 26. In the official Docker images, Node.js 24 has been replaced with 26.

What this means for website teams

Before upgrading, developers would do well to run tests with their own configuration and check TypeScript classes, elements with inert, cookie and proxy behavior, and element lookups by accessible name. If tests are distributed across shards, they should find out whether their pipeline permits a run that finds no tests at all. Teams trying Bun should compare its limitations with the way they normally investigate failures beforehand.

For website owners and marketers, the choice of runtime matters less than how confidently the team can verify changes to the site. A short report helps focus attention on problematic scenarios. But after the upgrade, a familiar test might find an element differently or wait for it to become interactive: developers will need to investigate that failure before trusting the run’s results.

My take: upgrade with a checklist

I like a report where failures do not get lost among lines of successful tests. And -exclusive- makes more sense to me than running the whole suite sequentially for the sake of one test that needs some quiet. Performance tests are not particularly fond of company anyway.

I would not switch to Bun in one move, though. If changing runners takes away familiar debugging clues, investigating a failure could take longer than the run saved. I would check the limitations first, then run the existing scenarios—especially TypeScript and accessibility tests. Otherwise, it is the familiar story: you upgrade a tool and end up fixing a button.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. Вышел Playwright 1.65: поддержка Bun, отчёты только с ошибками и изменения в запуске тестов habr.com

About the author

Domas from Kaunas

junior frontend developer

I’m learning through projects and occasionally fix other people’s styles, which apparently wrote themselves. I like pages that load quickly and don’t need three build tools just for a button.

All posts by the author