This release fixes database corruption in the `isolatedPerTestSnapshot` fixture and removes its per-test cache clear, so snapshot-isolated tests are both more reliable and faster. ⚠️ Breaking Changes ## Node.js 22.16.0 or later is now required The `engines` requirement has changed from `^20.19.0 || >=22.12.0` to `>=22.16.0`. Snapshot copying now uses Node's built-in `node:sqlite` module, which isn't available on Node 20. CI now tests against Node.js 22, 24 and 26. 🐛 Bug Fixes ## Snapshot restore no longer corrupts the sqlite database (#3581279) Drupal runs sqlite in WAL mode, so copying the database file directly was unsafe. Recent commits could exist only in the `-wal` file, and requests from the previous test that were still running (e.g. CSP reports or auto-saves the browser had abandoned) could still be writing to the database. Overwriting the file under them could fail with `database disk image is malformed`. Snapshots are now taken and restored with sqlite's [online backup API](https://www.sqlite.org/backup.html). It takes sqlite's own locks, includes everything in the WAL, and replaces the destination atomically. If a running request holds the destination locked, the copy retries for up to 60 seconds. This also applies to saving and restoring the on-disk snapshot cache (`snapshotCache`). ## No more cache clear before each snapshot test `isolatedPerTestSnapshot` used to log in as admin, clear all caches and log out before every test. This stopped APCu-cached state from the previous test leaking into the next one, but it made every test slower. The snapshot is now taken without the `last_write_timestamp_*` cache entries. After each restore, Drupal's `ChainedFastBackend` therefore ignores anything the previous test left in APCu, and the cache clear isn't needed. The database cache tables are restored with the database, so each test still starts with a warm cache. 📚 Documentation - Added a **Requirements** section to the README. - Added a **What the restore covers** section explaining what `isolatedPerTestSnapshot` restores before each test: the database and the `files` and `private` directories, but not other site files such as `settings.php`. - The guidance on `./`-relative paths and the ESLint plugin has moved to a new **Sites in a subdirectory** section at the end of the README. Relative paths are now described as needed only when a site may be served from a subdirectory.