Tags give the ability to mark specific points in history as being important
-
v2.0.0
protectedc823a825 · ·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.
-
v1.3.0
protectedb3726522 · ·This release adds module uninstallation, a configurable install profile for the parallelWorker fixture, and an ESLint plugin to catch root-relative paths that break on Drupal.org CI. ✨ New Features A new `drupal.uninstallModules(modules: string[])` method uninstalls modules via the UI, handling the confirmation step. It throws a clear error if a module isn't installed, or can't be uninstalled because another module depends on it or it has content that must be deleted first. The `parallelWorker` fixture now accepts a worker-scoped `installProfile` option (default `'minimal'`), which is passed to `Drupal.install()`: ```typescript import { parallelWorker as test } from '@drupal/playwright'; test.use({ installProfile: 'standard' }); ``` Tests declaring different profiles run in separate workers, each with its own site install. Drupal may be installed in a subdirectory (e.g. `http://localhost/web/` on Drupal.org CI), so a leading `/` in `page.goto()`, `waitForURL()`, `toHaveURL()` or `page.request` drops that path and tests 404 in CI despite passing locally. Always use `./`-relative paths, and add the new ESLint plugin to catch (and `--fix`) root-relative ones: ```js import drupalPlaywright from '@drupal/playwright/eslint'; export default [ // ... drupalPlaywright.configs.recommended, ]; ``` The fixtures now also add the trailing slash `baseURL` needs for relative paths to resolve correctly. 🐛 Bug Fixes - `Drupal.logout()` no longer asserts the presence of an `h1` that isn't guaranteed to be there. - Added the missing `"default"` export condition to `package.json`. - A pre-commit hook now regenerates the API docs automatically. -
v1.2.0
protectedc8eb958d · ·This release introduces snapshot-based test isolation, giving each test full isolation without paying the cost of a full site reinstall every time. ✨ New Features ## isolatedPerTestSnapshot fixture A new fixture that installs the Drupal site once per worker, then restores a database/filesystem snapshot before each test instead of reinstalling. You get the same per-test isolation guarantees as isolatedPerTest, but tests run much faster in situations where there is a heavy install profile, recipes, or other long-running repeated processes. - Requires sqlite (DRUPAL_TEST_DB_URL set to a sqlite:// URL). Snapshot/restore works by copying the standalone sqlite DB file and managed file directories; with any other database the fixture throws immediately. - Worker-scoped configuration via test.use({ ... }): | Option | Default | Description | |----------------------|-----------|------------------------------------------------------------------------------------------| | installProfile | 'minimal' | Install profile passed to Drupal.install() | | modules | [] | Modules installed declaratively before the snapshot | | enableTestExtensions | false | Make Drupal's test-only modules discoverable | | setup | undefined | Hook ({}, { drupal, page }) => Promise<void> for arbitrary setup baked into the snapshot | | snapshotCache | false | Reuse a worker's snapshot across runs while code is unchanged | - Cache is keyed by a fingerprint of the installProfile, modules, enableTestExtensions, resolved DB/base URL, and the git working-tree state of the Drupal root - *.spec.ts files are excluded from the fingerprint by default (configurable via testFileGlobs), so editing tests reuses the cache while changing source rebuilds it - Stale snapshots are pruned automatically; only the current fingerprint is kept - Requires git (or an explicit key), otherwise caching disables itself with a warning rather than risk a stale snapshot - Override at runtime with `DRUPAL_TEST_SNAPSHOT_CACHE=0|1 `(handy: on locally, off in CI) or `DRUPAL_TEST_SNAPSHOT_CACHE_DIR` ### setup hook for snapshot tests A worker-scoped setup hook lets you bake arbitrary setup (beyond profile/modules) into the snapshot. ## Screenshots on setup failure When a fixture's setup phase throws, a screenshot is now captured automatically to aid debugging. ## Other Changes - File-wide fixture options can now be passed through test.use({ installProfile, modules, enableTestExtensions }). - Updated snapshot cache and support for Drupal 11.4.