Forem: Vitali Haradkou

TypeScript knows your SQL is broken before your tests even run

Vitali Haradkou — Mon, 13 Apr 2026 08:15:00 +0000

You're writing a Playwright test. You need to seed some rows first. You write:

const result = await db.query('SELECT * WHERE id = ?', [42]);

TypeScript: 🤷 looks fine to me.

Your test runner: also fine.

Your database at 2 AM: ERROR: syntax error at or near "WHERE"

What if TypeScript could catch that? Not at runtime. Not in the test. At the type level, before anything runs.

Spoiler: it can.

The trick: SQL grammar as TypeScript types

TypeScript's template literal types let you match string patterns recursively. You can model a finite-state machine entirely within the type system.

Here is a tiny slice of what that looks like:

type Head<S extends string> =
  S extends `${infer H} ${infer _}` ? H : S;

type Tail<S extends string> =
  S extends `${infer _} ${infer T}` ? T : "";

type StateAfterSELECT<S extends string, Full extends string> =
  S extends ""
    ? never                                       // no FROM → invalid
    : Uppercase<Head<S>> extends "FROM"
      ? StateAfterFROM<Tail<S>, Full>             // found FROM → next state
      : StateAfterSELECT<Tail<S>, Full>;          // consume token, recurse

Walk the SQL token by token. Each state knows what tokens are valid next. If you reach an accepting state, return the parameter tuple. If not, return never.

What you actually get

import type { SQLParams } from '@playwright-labs/sql-core';

type A = SQLParams<'SELECT * FROM users WHERE id = ?'>;
//   ^-- [unknown]  ✅

type B = SQLParams<'SELECT * WHERE id = ?'>;
//   ^-- never  ❌ missing FROM

type C = SQLParams<'UPDATE users WHERE id = ?'>;
//   ^-- never  ❌ missing SET

type D = SQLParams<'SELECT * FROM t WHERE id = $3'>;
//   ^-- never  ❌ $1 and $2 are missing (sequential validation!)

That last one is my favourite. If you jump from $1 straight to $3, the type system notices.

How it connects to real queries

The sql function wraps this type system into something usable:

import { sql } from '@playwright-labs/sql-core';

const q1 = sql("SELECT * FROM users WHERE id = ?");
// typeof q1 → SqlStatement<[unknown]>

const q2 = sql("SELECT * WHERE id = ?");
// typeof q2 → never  ❌ compile error right here

SqlStatement<P> is a branded string that carries the parameter count. The SqlClient interface uses it to enforce the params array:

await client.query(q1, [42]);    // ✅
await client.query(q1);          // ❌ params required
await client.query(q1, [1, 2]);  // ❌ too many params

This is not a runtime check. TypeScript catches all three at compile time.

The Playwright fixture

The type safety story is nice. But in practice, the bigger pain with database tests is the connection boilerplate:

// without fixture-sql — every. single. test. file.
let db: Client;
beforeEach(async () => { db = await pgConnect(); });
afterEach(async () => { await db.end(); });

With @playwright-labs/fixture-sql:

import { test, expect } from '@playwright-labs/fixture-sql';
import { sqliteAdapter } from '@playwright-labs/fixture-sql/sqlite';

test.use({ sqlAdapter: sqliteAdapter(':memory:') });

test('insert and read', async ({ sql: db }) => {
  await db.execute(sql`CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)`);
  await db.execute(sql`INSERT INTO users VALUES (1, 'Alice')`);

  const { rows } = await db.query<{ name: string }>(
    sql("SELECT name FROM users WHERE id = ?"),
    [1],
  );
  expect(rows[0]!.name).toBe('Alice');
});

One test.use() call. Connection opens before the test, closes after it — even if the test throws. Each test gets a fresh in-memory SQLite database.

The language server plugin

There's also @playwright-labs/ts-plugin-sql: a TypeScript language service plugin that gives you:

Autocomplete for table names and column names inside sql templates
Diagnostics as squiggly underlines in your editor (before you even run a type check)
Hover info showing column types from your actual schema

Configure it in tsconfig.json:

{
  "compilerOptions": {
    "plugins": [{
      "name": "@playwright-labs/ts-plugin-sql",
      "schemaFile": "./src/db-types.ts"
    }]
  }
}

Generate db-types.ts from a live database:

pnpm playwright-labs-fixture-sql pull --adapter sqlite --url ./dev.db --out ./src/db-types.ts

Then

sql`SELECT ...` // rest

Your editor will offer id, name, email from the real schema.

Quick recap

Problem	Solution
SQL typos caught at runtime	`SQLParams<S>` returns `never` for invalid SQL
Wrong param count	`SqlStatement<P>` brand enforces the array
Missing `FROM`, `SET`, etc.	TypeScript FSM validates structure
`$3` without `$1`/`$2`	Sequential validation via `MinusOne<N>` type
Connection boilerplate	`fixture-sql` handles lifecycle
No editor SQL support	`ts-plugin-sql` language server plugin

Try it

pnpm add -D @playwright-labs/fixture-sql @playwright-labs/ts-plugin-sql
pnpm add -D better-sqlite3

The source is at github.com/vitalics/playwright-labs.

My question for you: what's the weirdest SQL bug you've shipped to production that a type system could have caught? Drop it in the comments 👇

Testing Angular Components by Properties with Playwright

Vitali Haradkou — Thu, 02 Apr 2026 12:40:00 +0000

Most Angular E2E tests look like this:

await page.locator('[data-testid="submit-btn"]').click();
await page.locator('.user-card:nth-child(2) h2').textContent();

You end up fighting CSS specificity and fragile DOM structure instead of testing Angular behavior. What if you could do this instead?

await page.locator('angular=app-button[label="Submit"]').click();
await page.locator('angular=app-user-card[user.role="admin"]').textContent();

That's exactly what @playwright-labs/selectors-angular provides.

What Is It?

A custom Playwright selector engine that queries Angular components by their actual component properties — @Input() values, signals, and nested objects — rather than DOM attributes or CSS classes.

It hooks into Angular's DevTools API (window.ng) which is available in development builds.

Installation

npm install -D @playwright-labs/selectors-angular

Setup

import { defineConfig } from "@playwright/test";
import { AngularEngine } from "@playwright-labs/selectors-angular";

export default defineConfig({
  use: {
    /* ... */
  },
});

// Register once at module level
import { selectors } from "@playwright/test";
selectors.register("angular", AngularEngine);

Or use the bundled test fixture which handles registration automatically:

import { test, expect } from "@playwright-labs/selectors-angular";

test("my angular test", async ({ page, $ng }) => {
  // $ng and engine are auto-registered
});

The `angular=` Selector Syntax

The syntax mirrors CSS attribute selectors:

angular=<component-tag>[property="value"][another="value"]

Operators

Operator	Meaning	Example
`[prop]`	truthy check	`[disabled]`
`[prop="val"]`	exact match	`[label="Submit"]`
`[prop*="val"]`	contains	`[type*="ary"]`
`[prop^="val"]`	starts with	`[type^="prim"]`
`[prop$="val"]`	ends with	`[type$="ger"]`
`[prop~="val"]`	word in list	`[classes~="active"]`
`[prop\	="val"]`	exact or hyphen-prefix

You can also use regex:

page.locator('angular=app-button[label=/^Sub/i]')

And case-insensitive with i flag:

page.locator('angular=app-button[label="submit" i]')

Nested Properties

Dot notation works for nested objects:

page.locator('angular=app-user-card[user.role="admin"]')
page.locator('angular=app-card[config.theme.color="dark"]')

Multiple Conditions (AND)

Chain multiple attribute blocks — all must match:

page.locator('angular=app-button[type="danger"][disabled]')

The `$ng` Fixture

The $ng fixture wraps standard Playwright locators with Angular-aware introspection methods:

test("inspects component state", async ({ $ng }) => {
  // Read @Input value
  const label = await $ng("app-button").first().input<string>("label");
  expect(label).toBe("Submit");

  // Read WritableSignal value
  const count = await $ng("app-counter").first().signal<number>("count");
  expect(count).toBe(0);

  // List all @Input names
  const inputs = await $ng("app-button").first().inputs();
  expect(inputs).toContain("label");
  expect(inputs).toContain("disabled");

  // Check directives
  const directives = await $ng("router-outlet").directives();
  expect(directives.some((d) => d.includes("RouterOutlet"))).toBe(true);
});

Narrowing

const buttons = $ng("app-button");
const first = buttons.first();
const second = buttons.nth(1);
const last = buttons.last();

Custom Matchers

Import the extended expect from the package:

import { expect } from "@playwright-labs/selectors-angular";

test("matchers", async ({ page }) => {
  const button = page.locator("app-button").first();

  // Is it an Angular component?
  await expect(button).toBeNgComponent();

  // Does it declare this @Input?
  await expect(button).toHaveNgInput("label");

  // Does the @Input hold this value?
  await expect(button).toBeNgInput("label", "Submit");

  // Does it declare this @Output?
  await expect(button).toHaveNgOutput("clicked");

  // Signal assertions
  const counter = page.locator("app-counter").first();
  await expect(counter).toHaveNgSignal("count");
  await expect(counter).toBeNgSignal("count", 0);
});

Real-World Example

Here's a test that checks a disabled danger button exists and has the right label:

test("danger button is disabled and labeled Delete", async ({ page, $ng }) => {
  await page.goto("/");

  // Use the selector engine to find it
  const btn = page.locator('angular=app-button[type="danger"][disabled]');
  await expect(btn).toHaveCount(1);

  // Use the fixture to read its label
  const label = await $ng('angular=app-button[type="danger"][disabled]').input<string>("label");
  expect(label).toBe("Delete");
});

Compare that to the equivalent DOM-based test:

// Before: fragile, depends on implementation details
const btn = page.locator('[data-testid="delete-btn"]');
await expect(btn).toBeDisabled();

The Angular-aware test is self-documenting — it describes the component contract, not the DOM structure.

Requirements

Angular app running in development mode (ng serve or ng build --configuration=development)
Playwright 1.40+
Angular 14+ (DevTools API required)

Wrapping Up

@playwright-labs/selectors-angular closes the gap between how Angular apps are built (component trees with typed inputs) and how they're tested (brittle CSS selectors). By querying components by their properties, your tests:

Break less when the DOM changes
Read like documentation
Test the Angular contract, not the DOM implementation

Check out the playwright-labs repository for more packages in the ecosystem.

Sending beautiful Playwright test reports via email using shadcn/ui and react-email

Vitali Haradkou — Tue, 31 Mar 2026 04:06:58 +0000

Why email reports?

After a CI run finishes you usually have two options: check GitHub Actions manually or wait for a Slack ping with a link. Neither is great when you want the whole team — including non-engineers — to see what broke.

@playwright-labs/reporter-email solves this by hooking into Playwright's reporter API and sending an HTML email as soon as the run completes. No extra server, no external service — just SMTP.

New in this release: shadcn/ui templates

The package now ships 4 new templates built on top of email-safe shadcn/ui components.

"Email-safe" means no Radix UI (requires browser APIs), no CSS variables (not supported in most clients), and <a> tags instead of <button> for interactive elements.

Template overview

Template	Import	Key feature
Base	`…/shadcn`	Badge + Card layout
Chart	`…/shadcn/base-chart`	Pass-rate stacked bar
Button	`…/shadcn/base-button`	CTA links to report / failures
Themes	`…/shadcn/base-themes`	6 color themes
Select	`…/shadcn/base-select`	Status filter

Subpath exports

Each template ships as its own bundle so you only import what you use:

import { PlaywrightReportShadcnChartEmail }
  from "@playwright-labs/reporter-email/templates/shadcn/base-chart";

TypeScript resolves types correctly with "moduleResolution": "bundler" in tsconfig.json.

Quick setup

Install the package:

npm install @playwright-labs/reporter-email

Add to playwright.config.ts:

import type { PlaywrightTestConfig } from "@playwright/test";

const config: PlaywrightTestConfig = {
  reporter: [
    ["@playwright-labs/reporter-email", {
      host: "smtp.example.com",
      port: 587,
      from: "ci@example.com",
      to: ["team@example.com"],
      template: "shadcn",          // or "shadcn-chart", "shadcn-themes", …
      statusFilter: ["failed"],    // send only failures
    }],
  ],
};

export default config;

The templates

The most useful pattern for busy pipelines: send an email only when something breaks, and show only the failed tests.

import PlaywrightReportShadcnEmail from
  "@playwright-labs/reporter-email/templates/shadcn/base-button";

<PlaywrightReportShadcnEmail
  result={result}
  testCases={testCases}
/>

The email renders a shadcn-like button trigger showing.

Previewing templates locally

The examples/ directory has a dev server powered by react-email:

cd packages/reporter-email/examples
pnpm email:preview
# → http://localhost:3000

In your project:

# install @react-email/components & @react-email/render 
pnpm i @react-email/components @react-email/render -D

Create template & Start dev server

mkdir -p ./emails
pnpm exec email dev --dir emails

Create your template:

import React from "react";
import type { FullResult, TestCase, TestResult } from "@playwright/test/reporter";
import PlaywrightReportEmail from "@playwright-labs/reporter-email/templates/base";

// mock data
const result = {
  status: "failed",
  duration: 14_320,
  startTime: new Date(),
} satisfies FullResult;

function tc(title: string, suite: string): TestCase {
  return { title, parent: { title: suite } } as unknown as TestCase;
}

function tr(status: TestResult["status"], duration: number): TestResult {
  return { status, duration } as TestResult;
}

const testCases: [TestCase, TestResult][] = [
  [tc("Login with valid credentials",   "Auth"),          tr("passed",  342)],
  [tc("Login with invalid credentials", "Auth"),          tr("passed",  289)],
  [tc("Logout",                         "Auth"),          tr("passed",  190)],
  [tc("Add item to cart",               "Shopping Cart"), tr("failed", 5102)],
  [tc("Remove item from cart",          "Shopping Cart"), tr("failed", 4320)],
  [tc("View product details",           "Product"),       tr("passed",  421)],
  [tc("Filter by category",             "Product"),       tr("passed",  374)],
  [tc("Search by keyword",              "Search"),        tr("skipped",   0)],
];

// your template!
/** Default export is required by the React Email dev server. */
export default function PlaywrightReportPreview() {
  return (
     <>
      <span> This is an example preview</span>
    <PlaywrightReportEmail result={result} testCases={testCases} />
     </>
  );
}

Check out the repo for all preview files and the full source.

GitHub: https://github.com/vitalics/playwright-labs

Real Docker Containers in Playwright Tests — Zero Boilerplate

Vitali Haradkou — Fri, 27 Mar 2026 09:30:31 +0000

You want real infrastructure in your integration tests. You don't want to write cleanup code. Here is how to get both.

The problem with containers in Playwright today

Testcontainers works great in Node.js, but fitting it into Playwright requires manual lifecycle management:

// the old way — lots of ceremony
let container: StartedTestContainer;

test.beforeAll(async () => {
  container = await new GenericContainer("redis:8")
    .withExposedPorts(6379)
    .start();
});

test.afterAll(async () => {
  await container.stop(); // what if beforeAll threw halfway through?
});

test("my test", async () => {
  const port = container.getMappedPort(6379);
  // ...
});

Problems:

If beforeAll fails midway, afterAll still runs and may throw on container.stop() against an undefined value.
All tests in the file share one container — isolation suffers.
The container setup has nothing to do with what you're testing, but it's taking up a third of your file.

The new way

npm install -D @playwright-labs/fixture-testcontainers testcontainers

import { test } from "@playwright-labs/fixture-testcontainers";

test("redis test", async ({ useContainer }) => {
  const container = await useContainer("redis:8", { ports: 6379 });
  const port = container.getMappedPort(6379);
  // container.stop() is called automatically after the test
});

That's it. One import change, and you get:

✅ Container starts when the test needs it
✅ Container stops after the test ends (even on failure)
✅ Multiple containers tracked and stopped in parallel
✅ Full ContainerOpts support — all GenericContainer.with* methods

Quick examples

Postgres with wait strategy

import { test } from "@playwright-labs/fixture-testcontainers";
import { Wait } from "testcontainers";

test("postgres integration", async ({ useContainer }) => {
  const pg = await useContainer("postgres:16", {
    ports: 5432,
    environment: { POSTGRES_PASSWORD: "secret" },
    waitStrategy: Wait.forLogMessage("ready to accept connections"),
    startupTimeout: 30_000,
  });

  const connStr = `postgresql://postgres:secret@localhost:${pg.getMappedPort(5432)}/postgres`;
  // connect and run queries
});

Multiple containers at once

test("full stack", async ({ useContainer }) => {
  const [redis, pg] = await Promise.all([
    useContainer("redis:8", { ports: 6379 }),
    useContainer("postgres:16", {
      ports: 5432,
      environment: { POSTGRES_PASSWORD: "secret" },
    }),
  ]);
  // both stop in parallel after the test
});

Build from Dockerfile

test("custom service", async ({ useContainerFromDockerFile }) => {
  const app = await useContainerFromDockerFile("./docker", "Dockerfile", {
    ports: 3000,
    waitStrategy: Wait.forHttp("/health", 3000),
  });
});

Compose with your own fixtures

Because useContainer is a Playwright fixture, it plugs directly into your existing fixture chain:

// fixtures.ts
import { test as base } from "@playwright-labs/fixture-testcontainers";

export const test = base.extend<{ redisUrl: string }>({
  redisUrl: async ({ useContainer }, use) => {
    const container = await useContainer("redis:8", { ports: 6379 });
    await use(`redis://${container.getHost()}:${container.getMappedPort(6379)}`);
  },
});

// my.spec.ts — tests never touch Docker at all
import { test } from "./fixtures";

test("cache behavior", async ({ redisUrl }) => {
  // just use the URL
});

Custom matchers

Import expect from the package to unlock container-specific assertions:

import { test, expect } from "@playwright-labs/fixture-testcontainers";

test("container assertions", async ({ useContainer }) => {
  const container = await useContainer("postgres:16", {
    ports: 5432,
    environment: { POSTGRES_PASSWORD: "secret" },
    healthCheck: { test: ["CMD-SHELL", "pg_isready -U postgres"], interval: 1_000, retries: 5 },
    waitStrategy: Wait.forHealthCheck(),
  });

  await expect(container).toBeContainerRunning();
  await expect(container).toBeContainerHealthy();
  expect(container).toBeContainerPort(5432);
  await expect(container).toMatchContainerLogMessage("ready to accept connections");
  expect(container).toMatchContainerPortInRange(5432, { min: 1024 });
});

Full matcher list:

Matcher	What it checks
`toBeContainerRunning()`	`State.Running === true`
`toBeContainerStarted()`	`State.Status === "running"`
`toBeContainerStopped()`	`State.Status === "exited"`
`toBeContainerHealthy()`	`State.Health.Status === "healthy"`
`toMatchContainerLogMessage(pattern)`	Logs contain string or match RegExp
`toBeContainerPort(port)`	Port is exposed and mapped
`toMatchContainerPortInRange(port, range?)`	Mapped port is within bounds
`toHaveContainerLabel(key, value?)`	Label exists (optionally with value)
`toHaveContainerName(name)`	Exact name match
`toMatchContainerName(pattern)`	Name contains / matches RegExp
`toHaveContainerNetwork(name)`	Connected to the network
`toHaveContainerUser(user?)`	Exact user or any non-empty user
`toMatchContainerUser(pattern)`	User contains / matches RegExp

All .not variants are supported.

Requirements

@playwright/test >= 1.57.0
testcontainers >= 10.0.0
Docker (local or CI)

Source: github.com/vitalics/playwright-labs

If you've been putting off writing integration tests because of the Docker lifecycle boilerplate, this is the package that removes that excuse. Give it a try and let me know what you think in the comments!

Stop Throwing Exceptions. Use Option and Result Instead.

Vitali Haradkou — Fri, 20 Feb 2026 12:10:29 +0000

Let's talk about what's wrong with JavaScript error handling. Here's a function:

function getUser(id: number): User | null {
  // ...
}

The caller has to remember to null-check. The type system nudges them, but there's nothing stopping this:

const user = getUser(42);
console.log(user.name); // TypeError at runtime if user is null

Or this pattern, which is even worse:

async function fetchConfig(): Promise<Config> {
  // can throw network error, parse error, validation error...
  // none of these appear in the type signature
}

The errors are invisible. The caller doesn't know what to handle.

There's a better model

Rust has Option<T> for values that might not exist, and Result<T, E> for operations that can fail. Both are explicit in the type signature. Both force the caller to handle every case.

@rslike/std brings this to TypeScript.

npm i @rslike/std

Option — make absence impossible to ignore

import { Some, None, Option, match } from "@rslike/std";

function findUser(id: number): Option<User> {
  const user = db.find(u => u.id === id);
  return user ? Some(user) : None();
}

Now the caller must handle both states. They can't accidentally treat None as a value:

const opt = findUser(42);

// Safe extraction with fallback
const user = opt.unwrapOr(guestUser);

// Pattern matching — handles both branches exhaustively
const greeting = match(
  opt,
  (user) => `Hello, ${user.name}!`,
  ()     => "Hello, guest!"
);

Transform without unwrapping

const displayName = findUser(42)
  .map(u => `${u.firstName} ${u.lastName}`)
  .unwrapOr("Unknown User");

// Chain operations that also return Option
const avatar = findUser(42)
  .flatMap(u => findAvatar(u.avatarId))
  .unwrapOr(defaultAvatar);

Quick checks

const opt = Some("hello");

opt.isSome();     // true
opt.isNone();     // false
opt.unwrap();     // "hello"

const empty = None();
empty.isNone();   // true
empty.unwrapOr("fallback"); // "fallback"
empty.unwrap();   // throws UndefinedBehaviorError — intentional!

Result — make errors part of the contract

import { Ok, Err, Result, match } from "@rslike/std";

function divide(a: number, b: number): Result<number, string> {
  return new Result((ok, err) => {
    if (b === 0) {
      err("Division by zero");
    } else {
      ok(a / b);
    }
  });
}

The error type is in the signature. Callers know what to expect:

const r = divide(10, 2);

r.isOk();   // true
r.unwrap();  // 5

const bad = divide(10, 0);
bad.isErr();             // true
bad.unwrapErr();         // "Division by zero"
bad.unwrapOr(0);         // 0

Wrapping existing code that throws

function parseJSON(raw: string): Result<unknown, SyntaxError> {
  return new Result((ok, err) => {
    try {
      ok(JSON.parse(raw));
    } catch (e) {
      err(e as SyntaxError);
    }
  });
}

const config = parseJSON(rawInput)
  .map(data => validate(data))
  .mapErr(e => `Invalid config: ${e.message}`)
  .unwrapOr(defaults);

Pattern matching

const message = match(
  parseJSON(rawInput),
  (data) => `Loaded: ${JSON.stringify(data)}`,
  (err)  => `Error: ${err.message}`
);

`match` — exhaustive two-branch dispatch

match works with Option, Result, and boolean:

import { match } from "@rslike/std";

// boolean
match(isAdmin, (t) => "admin panel", (f) => "dashboard");

// Option<string>
match(someOption, (value) => `Got: ${value}`, () => "nothing");

// Result<number, Error>
match(someResult, (n) => n * 2, (e) => -1);

TypeScript infers the callback parameter types from the input — you can't accidentally use the error handler as the success handler.

Globals — skip the imports

// entry.ts — once
import "@rslike/std/globals";

// anywhere else in your app — no imports needed
const x = Some(42);
const r = Ok("success");
const n = None();
const e = Err(new Error("oops"));

The real benefit

When Option and Result are in your function signatures, code review becomes a conversation about intent rather than a hunt for unhandled edge cases.

// Before: what does null mean here? forgotten value? intentional absence?
function getSession(token: string): Session | null

// After: clear contract — either a session or nothing
function getSession(token: string): Option<Session>

// Before: can this throw? which errors?
async function createOrder(cart: Cart): Promise<Order>

// After: explicit failure type in the signature
async function createOrder(cart: Cart): Promise<Result<Order, OrderError>>

Install

npm i @rslike/std

Source: github.com/vitalics/rslike

Have you used Option/Result patterns in TypeScript before? What library are you using? Let me know below.

Stop Leaking Resources: How to Use AbortSignal in Playwright Tests

Vitali Haradkou — Mon, 16 Feb 2026 11:19:17 +0000

If you write Playwright tests that make HTTP requests, call APIs, or perform any long-running async work, you probably have a resource leak problem you do not know about.

In this tutorial, I will walk you through the problem, explain why standard cleanup patterns fall short, and show you how to integrate AbortController / AbortSignal into your Playwright tests using the @playwright-labs/fixture-abort package.

The Problem: Zombie Requests After Test Timeouts

Consider a straightforward Playwright test that calls an API:

test('should fetch user profile', async () => {
  const response = await fetch('https://api.example.com/users/123');
  const user = await response.json();
  expect(user.name).toBe('Alice');
});

If this test times out - maybe the API is slow, maybe the server is under load - Playwright stops the test. But the fetch call does not get cancelled. The request continues running until it either completes or hits its own timeout (often 30 seconds or more by default).

In isolation, this is harmless. At scale - hundreds of tests, multiple workers, CI running every push - it creates real problems:

Connection pool exhaustion: Your test infrastructure runs out of available connections.
Server overload: Your staging environment handles requests nobody is waiting for.
Misleading logs: Errors from orphaned requests appear in server logs, confusing debugging efforts.
Cascading failures: Resource exhaustion in one service affects others in your staging environment.

Why afterEach Does Not Solve This

Your first instinct might be to clean up in an afterEach hook. But there is a fundamental issue: by the time afterEach runs, you have no reference to the in-flight requests. The fetch promise is trapped inside the timed-out test function. You cannot cancel what you cannot reach.

What you need is a cancellation token that you pass into every async operation upfront - something that can be triggered externally when the test ends.

This is exactly what AbortController and AbortSignal were designed for.

Enter AbortSignal

AbortController is a web standard (also available in Node.js) that provides a mechanism for cancelling async operations:

const controller = new AbortController();
const signal = controller.signal;

// Pass signal to fetch
fetch('/api/data', { signal });

// Later, cancel the request
controller.abort(); // The fetch rejects with AbortError

The @playwright-labs/fixture-abort package wires this pattern directly into Playwright's test lifecycle.

Setting Up fixture-abort

Install the package:

npm install @playwright-labs/fixture-abort

The package extends Playwright's test with fixtures built in:

abortController - an AbortController instance, fresh for each test
signal - the associated AbortSignal
useAbortController(options?) - returns the controller with optional abort callback
useSignalWithTimeout(ms) - returns a signal that auto-aborts after the given duration

Import test and expect from the package instead of @playwright/test, and the fixtures are ready to use.

Basic Usage: Cancellable Fetch

Here is the simplest pattern - passing the signal to a fetch call:

import { test, expect } from '@playwright-labs/fixture-abort';

test('should fetch user profile', async ({ signal }) => {
  const response = await fetch('https://api.example.com/users/123', {
    signal
  });
  const user = await response.json();
  expect(user.name).toBe('Alice');
});

If the test times out, signal fires, and the fetch call is immediately cancelled. No orphaned request. No wasted server resources.

Pattern: Polling with Cooperative Cancellation

Many tests need to poll an endpoint until a condition is met. Without abort signals, a timeout leaves the polling loop running in the background. With signal, you get clean cooperative cancellation:

import { test, expect } from '@playwright-labs/fixture-abort';

test('should wait for order processing', async ({ signal }) => {
  const orderId = await createOrder();

  while (!signal.aborted) {
    const response = await fetch(`/api/orders/${orderId}`, {
      signal
    });
    const order = await response.json();

    if (order.status === 'completed') {
      expect(order.total).toBeGreaterThan(0);
      return;
    }

    // Wait 2 seconds before next poll
    await new Promise(resolve => setTimeout(resolve, 2000));
  }
});

The while (!signal.aborted) check means the loop exits cleanly when the signal fires. The fetch call inside the loop is also protected by the same signal. Double coverage.

Pattern: Multiple Parallel Requests

When a test fires multiple requests in parallel, all of them need to be cancellable:

import { test, expect } from '@playwright-labs/fixture-abort';

test('should fetch dashboard data', async ({ signal }) => {
  const [users, orders, metrics] = await Promise.all([
    fetch('/api/users', { signal }),
    fetch('/api/orders', { signal }),
    fetch('/api/metrics', { signal })
  ]);

  expect(users.ok).toBe(true);
  expect(orders.ok).toBe(true);
  expect(metrics.ok).toBe(true);
});

One signal, three requests, all cancelled together if the test times out.

Pattern: Manual Abort for Early Exit

You are not limited to timeout-driven cancellation. You can abort manually based on test logic:

import { test, expect } from '@playwright-labs/fixture-abort';

test('should stop on first error', async ({ signal, abortController }) => {
  const items = await getItemsToProcess();

  for (const item of items) {
    if (signal.aborted) break;

    const response = await fetch(`/api/process/${item.id}`, {
      method: 'POST',
      signal
    });

    if (!response.ok) {
      abortController.abort(); // Cancel remaining work
      break;
    }
  }
});

Pattern: Abort Controller with Callback

Use useAbortController to register a callback that fires on abort:

import { test, expect } from '@playwright-labs/fixture-abort';

test('should handle abort with cleanup', async ({ useAbortController, signal }) => {
  const controller = useAbortController({
    onAbort: () => console.log('Operation cancelled, cleaning up'),
    abortTest: true
  });

  const response = await fetch('/api/long-operation', { signal });
  const data = await response.json();
  expect(data).toBeDefined();
});

Pattern: Signal with Timeout

Use useSignalWithTimeout to get a signal that auto-aborts after a specific duration:

import { test, expect } from '@playwright-labs/fixture-abort';

test('should complete within 5 seconds', async ({ useSignalWithTimeout }) => {
  const timeoutSignal = useSignalWithTimeout(5000);

  const response = await fetch('/api/slow-endpoint', {
    signal: timeoutSignal
  });
  expect(response.ok).toBe(true);
});

Pattern: Passing Signal to Third-Party Libraries

Many modern libraries accept an AbortSignal. You can pass signal to anything that supports it:

import { test, expect } from '@playwright-labs/fixture-abort';

test('should query database', async ({ signal }) => {
  // Many DB clients accept abort signals
  const result = await db.query('SELECT * FROM users', {
    signal
  });
  expect(result.rows.length).toBeGreaterThan(0);
});

This works with Axios (via signal option), the Node.js fetch implementation, many database drivers, gRPC clients, and more.

Custom Expect Matchers

The package also provides custom expect matchers for testing abort states:

import { test, expect } from '@playwright-labs/fixture-abort';

test('should verify abort state', async ({ signal, abortController }) => {
  expect(signal).toBeActive();

  abortController.abort('test reason');

  expect(signal).toBeAborted();
  expect(signal).toBeAbortedWithReason('test reason');
  expect(abortController).toHaveAbortedSignal();
});

test('should verify timeout signal aborts', async ({ useSignalWithTimeout }) => {
  const timeoutSignal = useSignalWithTimeout(100);
  await expect(timeoutSignal).toAbortWithin(150);
});

How It Works Under the Hood

The implementation is straightforward:

Before each test, a fresh AbortController is created via Playwright's fixture system.
The controller and its signal are made available as abortController and signal fixtures.
When the test times out, the controller is aborted.
Any operation listening to the signal receives an AbortError and stops.
After each test, the controller is cleaned up.

This means every test gets its own isolated cancellation scope. One test timing out does not affect any other test.

Common Mistakes to Avoid

Do not create your own AbortController when the fixture provides one. The whole point is that the fixture's controller is wired into the test lifecycle. A manually created controller will not auto-abort on timeout.

Do not forget to pass the signal. An unprotected fetch() call without signal is still vulnerable to the zombie request problem. Make it a habit: every async operation gets the signal.

Do not swallow AbortError silently. When a signal fires, operations reject with AbortError. This is expected behavior during timeouts. Let Playwright handle the timeout reporting rather than catching and hiding the error.

Getting Started

npm install @playwright-labs/fixture-abort

Full source code and documentation: github.com/vitalics/playwright-labs

The package is part of the @playwright-labs monorepo. Import test and expect from @playwright-labs/fixture-abort instead of @playwright/test, and the abort fixtures are ready to use in every test.

Give it a try. Your staging servers will thank you.

Introducing Playwright Labs: Best Practices as Code

Vitali Haradkou — Tue, 20 Jan 2026 11:38:20 +0000

What is Playwright Labs?

Playwright Labs is a curated monorepo of skills and best practices designed specifically for modern testing workflows. Think of it as a knowledge base that integrates seamlessly with your development environment, providing contextual guidance powered by AI and LLM agents.

The first package in this collection is playwright-best-practices - a comprehensive guide to writing better, faster, and more reliable Playwright tests.

Video Overview

Watch this quick introduction to Playwright Labs and learn how to get started:

Why Playwright Labs?

Testing best practices are often scattered across documentation, blog posts, and tribal knowledge. Playwright Labs solves this by:

📚 Centralized Knowledge - All best practices in one structured repository
🤖 AI-Optimized - Formatted specifically for LLM consumption and agent workflows
🎯 Impact-Driven - Practices ranked by their impact on test quality
🔄 Always Updated - Community-driven and version-controlled
💻 Code-First - Every rule includes practical code examples

The playwright-best-practices Package

This package contains 8 categories of Playwright best practices, each with multiple rules and examples:

1. Test Stability & Reliability (CRITICAL)

Focus on eliminating flaky tests and ensuring consistent results.

2. Test Execution Speed (CRITICAL)

Optimize test performance for faster feedback loops.

3. Locator Best Practices (HIGH)

Master element selection strategies for robust tests.

4. Assertions & Waiting (HIGH)

Learn proper synchronization and validation techniques.

5. Parallel Execution (MEDIUM-HIGH)

Harness the power of parallel test execution.

6. Fixtures & Test Organization (MEDIUM)

Structure tests for maintainability and reusability.

7. Debugging & Maintenance (MEDIUM)

Streamline troubleshooting and test maintenance.

8. Advanced Patterns (LOW)

Explore advanced techniques for complex scenarios.

Installation

The package uses a unique installation method optimized for skill packages:

# Install via pnpx
pnpx add-skill https://github.com/vitalics/playwright-labs/tree/main/packages/playwright-best-practices

This command integrates the best practices directly into your development environment, making them accessible to AI coding assistants and LLM agents.

Repository Structure

packages/
└── playwright-best-practices/
    ├── rules/
    │   ├── stable-use-waitfor.md          # CRITICAL: Wait for elements
    │   ├── stable-avoid-timeouts.md       # Avoid hardcoded timeouts
    │   ├── speed-parallel-tests.md        # Enable parallel execution
    │   ├── locator-use-role.md            # Prefer role-based selectors
    │   ├── assertion-use-expect.md        # Use proper assertions
    │   └── ...                            # More rules...
    ├── src/
    │   ├── build.ts                       # Compile rules to AGENTS.md
    │   ├── validate.ts                    # Rule compliance checker
    │   └── extract-tests.ts               # Test case extractor
    ├── AGENTS.md                          # Auto-generated compiled output
    ├── metadata.json                      # Package metadata
    ├── test-cases.json                    # LLM evaluation tests
    ├── package.json
    └── README.md

Rule Format

Each rule follows a standardized format designed for both human and machine readability:

---
title: "Use proper waits instead of timeouts"
impact: CRITICAL
description: "Avoid hardcoded sleeps and use Playwright's built-in waiting"
tags: [stability, waiting, async]
---

## Problem

Using hardcoded timeouts makes tests slow and unreliable.

❌ **Bad:**
\`\`\`typescript
await page.goto('https://example.com')
await new Promise(resolve => setTimeout(resolve, 5000)) // Bad!
await page.click('button')
\`\`\`

✅ **Good:**
\`\`\`typescript
await page.goto('https://example.com')
await page.waitForLoadState('networkidle')
await page.click('button')
\`\`\`

## Why

Playwright has built-in auto-waiting that makes tests faster and more reliable.

Frontmatter Metadata

title - Clear, actionable rule name
impact - CRITICAL, HIGH, MEDIUM-HIGH, MEDIUM, or LOW
description - Optional detailed explanation
tags - Searchable categories

Key Best Practices Highlights

Let me share some of the most impactful practices from the package:

1. Use Built-in Auto-Waiting

Playwright automatically waits for elements to be ready. Don't fight it:

// ❌ Manual waiting
await page.waitForSelector("button");
await page.click("button");

// ✅ Auto-waiting (preferred)
await page.click("button"); // Automatically waits for button to be actionable

2. Prefer Role-Based Selectors

Use accessible locators for robust tests:

// ❌ Fragile CSS selectors
await page.click(".btn-primary");

// ✅ Semantic role selectors
await page.getByRole("button", { name: "Submit" }).click();

3. Use Test Fixtures

Organize common setup with fixtures:

// Define fixture
export const test = base.extend<{ authenticatedPage: Page }>({
  authenticatedPage: async ({ page }, use) => {
    await page.goto("/login");
    await page.fill('[name="username"]', "testuser");
    await page.fill('[name="password"]', "password");
    await page.click('button[type="submit"]');
    await use(page);
  },
});

// Use in tests
test("user dashboard", async ({ authenticatedPage }) => {
  await authenticatedPage.goto("/dashboard");
  await expect(authenticatedPage.getByText("Welcome")).toBeVisible();
});

4. Enable Parallel Execution

Maximize test speed with parallelization:

export default defineConfig({
  // Run tests in parallel across 4 workers
  workers: process.env.CI ? 2 : 4,

  // Fully parallel execution mode
  fullyParallel: true,

  // Retry failed tests
  retries: process.env.CI ? 2 : 0,
});

5. Use Proper Assertions

Playwright provides auto-retrying assertions:

// ❌ Manual checks (no retry)
const text = await page.locator(".status").textContent();
expect(text).toBe("Success");

// ✅ Auto-retrying assertions
await expect(page.locator(".status")).toHaveText("Success");

Impact Levels Explained

Rules are categorized by their impact on test quality:

Impact Level	Description	Focus Area
CRITICAL	Major improvements to stability or speed	Must implement
HIGH	Significant quality improvements	High priority
MEDIUM-HIGH	Notable benefits with some effort	Recommended
MEDIUM	Incremental improvements	Nice to have
LOW	Advanced patterns for specific cases	Optional

This prioritization helps teams focus on high-value practices first.

How AI Agents Use This

The package is optimized for LLM consumption through:

Structured Format - Consistent markdown with clear sections
AGENTS.md - Compiled single-file output for easy ingestion
Metadata - JSON metadata for programmatic access
Test Cases - Evaluation data for LLM fine-tuning
Clear Examples - Before/after code comparisons

AI coding assistants can:

Suggest best practices contextually
Detect anti-patterns in your code
Provide refactoring suggestions
Generate test code following best practices

Real-World Benefits

Teams using these practices report:

50-70% reduction in flaky tests
30-40% faster test execution
Improved maintainability - easier to update tests
Better debugging - clearer failure messages
Increased confidence - reliable CI/CD pipelines

What's Next for Playwright Labs?

The monorepo is designed for growth. Future packages might include:

playwright-api-testing - Best practices for API testing
playwright-mobile - Mobile testing patterns
playwright-performance - Performance testing techniques
playwright-accessibility - A11y testing guidelines
playwright-visual - Visual regression testing

Contributing

Playwright Labs is open-source and community-driven. You can contribute by:

Adding new rules - Share your hard-earned lessons
Improving existing rules - Better examples and explanations
Reporting issues - Found a problem? Let us know
Creating packages - New skill packages are welcome

Check out the repository: github.com/vitalics/playwright-labs

Conclusion

Playwright Labs represents a new way of sharing and learning best practices - one that's optimized for both human developers and AI assistants. The playwright-best-practices package is just the beginning.

By installing this skill package, you're not just getting documentation - you're getting an AI-powered testing advisor that helps you write better tests from day one.

Key Takeaways:

✅ 8 categories covering all aspects of Playwright testing
✅ Impact-ranked practices for focused improvements
✅ AI-optimized format for intelligent tooling
✅ Open-source and community-driven
✅ Easy installation via pnpx add-skill

Ready to level up your Playwright testing? Install the skill package and let AI-powered best practices guide your testing journey!

pnpx add-skill https://github.com/vitalics/playwright-labs/tree/main/packages/playwright-best-practices

Resources

Happy testing! 🎭

Made with ❤️ by Vitali!

[Boost] Playwright + email = nodemailer reporter

Vitali Haradkou — Sun, 03 Aug 2025 09:51:23 +0000

Vitali Haradkou

Aug 1 '25

Playwright + email = reporter

#playwright #testing #github #typescript

Comments

3 min read

Playwright + email = reporter

Vitali Haradkou — Fri, 01 Aug 2025 18:34:32 +0000

Recently, I received a request from one of the project leads about integrating with Email. Since the email report was generated by a playwright written using React. That means we cannot send the same HTML report due to the interactive behaviour of the built-in HTML reporter.

Requirements

Select when the report should be sent
Subject and body should be written in code.
Support many email services out of the box

Nice to have:

Generate an ICS meeting in case of a failed test due to the scheduled run.

So I started to investigate the solution and found that existing reports do not cover our needs. That starting point - time to tinkering!

How do I see myself when solving problems and tinkering

First of all, I take nodemailer as a dependency to send an email and check it.

After all, I was trying to add interfaces. Inspect the playwright built-in HTML reporter about settings and env variables. As for initial implementation, I was taking only the send setting with the same args: never, always and on-failure. Other settings like from, to, service reuse from nodemailer dependency and add env var support with predefined values like send (send default value is on-failure).

So let's check out how it works.

Step 1. Installation

just add dependency playwright-nodemailer-reporter via any package manager:

npm i playwright-nodemailer-reporter # for npm
pnpm i playwright-nodemailer-reporter # for pnpm
yarn add playwright-nodemailer-reporter # for yarn

Step 2. playwright config

At this step, we have to add a reporter for Playwright. You can do it in the playwright.config.ts file

// filename: playwright.config.ts
import { defineConfig } from "@playwright/test";
import { type EmailReporterOptions } from "playwright-nodemailer-reporter";

export default defineConfig({
  reporter: [
    [
      "playwright-email-reporter",
      {
        send: 'always',
        from: "your-email@example.com",
        to: "recipient-email@example.com",
        subject: "Playwright Test Report",
        html: "<p>Test report</p>", # what will be send
      } satisfies EmailReporterOptions,
    ],
  ],
});

Step 3. Dynamic message

The next step was to make the message and subject dynamically generated. This is essential for the customer because we save a ton of time with building up the string. Moreover, subject, html and text keys support async function to call any of your external functions or async functions.

import { defineConfig } from "@playwright/test";
import { type EmailReporterOptions } from "playwright-email-reporter";

export default defineConfig({
  reporter: [
    [
      "playwright-email-reporter",
      {
        send: "always",
        service: "Maildev",
        port: 1025,
        from: "from@email.fr",
        to: "to@email.fr",
        subject: "Playwright Test Report",
        html: (result, testCases) => {
          return `
          HTML Result:
          <table>
            <tr>
              <th>Test Name</th>
              <th>Status</th>
            </tr>
            ${testCases
              .map(
                ([testCase, result]) => `
              <tr>
                <td>${testCase.title}</td>
                <td>${result.status}</td>
              </tr>
            `,
              )
              .join("")}
          </table>
          `;
        },
      } satisfies EmailReporterOptions,
    ],
  ],
});

In this example, we build a table with the test case name and its result.

The rendered result will be something like this:

You can also add Gmail or other popular services since the reporter just reused nodemailer.

Step 4. You are awesome!

Check it out on npm: https://www.npmjs.com/package/playwright-nodemailer-reporter
Check it out on GitHub: https://github.com/vitalics/playwright-nodemailer-reporter

P.S. I was faced with an issue when playwright-email-reporter and playwright-mail-reporter already existed, so I renamed the package, but the naming can be inconsistent with the package name. I'll try to fix it in the next release.

P.P.S. Check the other cool packages for everyday usage

Playwright promehteus remote write reporter
Playwright CPUPro reporter
Playwright Angular Selectors
ajv-ts
rslike. Rust-like safe approach for JS/TS code

Thanks for the reading and have a good time!
Made with ❤️ from Vitali!

It's time to fix JavaScript

Vitali Haradkou — Wed, 05 Mar 2025 09:25:25 +0000

JavaScript is powerful, but its error handling is a mess. nullish checks everywhere, cryptic undefined is not a function errors, and inconsistent Promise handling make debugging painful. It's time to fix it.

The Problem: JavaScript’s Broken Error Handling

JavaScript lacks a native, structured way to handle success and failure cases. You either:

Rely on try/catch/finally, which only works for thrown errors.

Use null or undefined, forcing endless manual checks.

Work with Promises that fail silently if not properly caught.

This results in fragile, unpredictable code. TypeScript helps with types, but it doesn’t fix JavaScript’s fundamental error-handling flaws.

The Solution: `@rslike/std`

Inspired by Rust’s Result and Option, @rslike/std introduces a structured way to handle errors and optional values.

1. Result: Explicit Success or Failure

import { Result } from "@rslike/std";

const safeDivide = (a: number, b: number) => {
  return new Result(() => {
    if (b === 0) throw new Error("Cannot divide by zero");
    return a / b;
  });
};

const result = safeDivide(10, 0);
console.log(result.unwrapOr("Error: Division failed"));

No more silent failures. You must handle both success and error cases.

2. Option: No More `null` or `undefined`

import { Option } from "@rslike/std";

const findUser = (id: number) => {
  return new Option(() => (id === 1 ? { name: "Alice" } : undefined));
};

const user = findUser(2);
console.log(user.unwrapOr("No user found"));

No need for if (user !== null), just structured, predictable code.

Why This Matters

Predictable: No more guessing if a function returns null, undefined, or an error.
Readable: Code clearly expresses intent—handling success and failure.
Safe: Eliminates unexpected runtime crashes.

Fix your JavaScript Today!

JavaScript’s error handling is broken, but we don’t have to accept it. @rslike/std brings clarity, safety, and sanity to your JavaScript/TypeScript projects. Try it out today:

👉 Install the package:

npm install @rslike/std
yarn add @rslike/std
pnpm add @rslike/std
bun add @rslike/std
deno add @rslike/std

🚀 Fix your JavaScript! Write better code!

github: https://github.com/vitalics/rslike/tree/main/packages/std
npm: https://www.npmjs.com/package/@rslike/std

Post Scriptum

I decided to pay for any (no matter pet or production) project that uses a @rslike/std package. You can contact me via email: vitalicset@gmail.com or via telegram vitalicset or comments to get more details.

Introducing Result & Option Constructor Control Flow in @rslike/std 3.1.0

Vitali Haradkou — Wed, 05 Mar 2025 05:14:26 +0000

RSLike is a collection of packages that ensures the safety of your Typescript/Javascript code without undefined/null checks.

The latest release of @rslike/std brings powerful new features and important fixes to enhance functional and OOP programming in TypeScript. In version 3.1.0, we've introduced improved control flow for Result and Option constructors, along with several fixes and updates.

`Result` & `Option` Constructors Control Flow

Now, you can create Result or Option instances using either Promises or direct return values. This makes error handling more flexible and intuitive.

import { Result, Option } from "@rslike/std";

// Constructor control flow
const result = new Result((ok, err) => {
  if (Math.random() > 0.5) {
    ok(42);
  } else {
    err("error");
  }
});

// Return control flow
const result2 = new Result(() => {
  if (Math.random() > 0.5) {
    return 42;
  } else {
    throw new Error("error");
  }
});

console.log(result2); // Result<42, Error> or Result<number, Error>

const option = new Option((some, none) => {
  if (Math.random() > 0.5) {
    some(42);
  } else {
    none();
  }
});

const opt2 = new Option(() => {
  throw new Error("error");
});

console.log(opt2.isNone()); // true

⚠ Note: Async functions and Promise return statements are not supported and will throw an error. Use Result.fromPromise instead.

import { Result } from "@rslike/std";

// ❌ Incorrect usage
new Result((ok, err) => {
  ok(Promise.resolve(42)); // Throws an error
});
// ❌ Incorrect usage
new Result(() => {
  return Promise.resolve(42); // Throws an error
});
// ❌ Incorrect usage
new Result(async () => {
  return "qwe"; // Throws an error
});

// ✅ Correct usage
async function someFn(){ /** implementation */} 
const result = await Result.fromPromise(someFn())

// ✅✅ Better usage - combine Result and Option for function - Bind
async function someFn(): number { /** implementation */} 
const binded = Bind(someFn)

const r = await binded() // Result<Option<number>>

`Option.fromPromise` & `Option.fromAsync`

Now you can safely create an Option from an async function or a Promise using the new Option.fromPromise or Option.fromAsync methods. Result has already been implemented in this functionality, so we retranslate the same logic from the Result class.

JS compatibility

Migrated status for Result and Option from enum to object.

Added assertion for passing constructor executor argument in Result and Option.

Fixed types for well-known symbols: Symbol.split, Symbol.search, Symbol.iterator, and Symbol.asyncIterator.

// before (Symbol.iterator)
const a = Some([1,2,3])
for(const el of a) {
       // ^ type el: number
}
// before (Symbol.asyncIterator)
for await (const el of a) { // no throws
       // ^ type el: number
}

// after (Symbol.iterator)
const a = Some([1,2,3])
for(const el of a) {
       // ^ type el: 1 | 2 | 3
}

// after (Symbol.asyncIterator)
for await (const el of a) { // throws, array does not implement Symbol.asyncIterator function
       // ^ type el: never
}

// before (Symbol.split)
const nonSplittable = Ok(5)
'some long string'.split(nonSplittable) // Ok in types, throws in execution

// after (Symbol.split)
const nonSplittable = Ok(5)
'some long string'.split(nonSplittable) // Error in types, throws in execution

'string to split'.split(Ok('to')) // Ok in types, no throw

Fixed inspection output results for Result and Option in Node.js.

Release notes: https://github.com/vitalics/rslike/releases/tag/%40rslike%2Fstd%403.1.0
Link to the project: https://github.com/vitalics/rslike/tree/main/packages/std

Ajv-ts got 0.9. What's new?

Vitali Haradkou — Mon, 16 Sep 2024 17:14:31 +0000

The latest Release 0.9 of the Schema Validation Toolkit - ajv-ts brings a suite of enhancements to improve developer productivity and ensure better validation accuracy. Whether you're building complex data models or just handling basic input, these updates help streamline schema definitions with more robust features and examples. Here's an overview of the key updates introduced in this release, along with a recap of the significant changes from Release 0.7.

Schema Examples for Better Clarity

One of the major updates in Release 0.9 is the introduction of schema examples for every data type. This feature, allows developers to include specific examples directly within their schema definitions, offering more transparency and ease of use. You can also use it with any argument length.

For Strings:

// Valid examples for a string schema
const myString = s.string().examples(["hello", "world"]);
myString.schema // // {type: 'string', examples: ['hello', 'world']}
s.string().examples("hello", "world"); // OKs

For Numbers:

// Valid examples for a number schema
const myNum1 = s.number().examples(1, 2, 3);
myNum1.schema // {type: 'number', examples: [1,2,3]}

// TypeScript error for invalid number types
// @ts-ignore fails ts, but schema still ok
const myNum2 = s.number().examples(["abc", "123"]);
myNum2.schema // {type: "number", examples: ["abc", "123"] }

This change helps validate the correct data types and improves documentation within your code, making it easier for teams to understand what values are expected.

Stricter Number Validation

It's also worth highlighting some of the significant changes introduced in the previous Release 0.8, which brought more rigorous number validation:

Format and Type Enforcement: This update introduced stricter rules for number formats. For instance, only specific combinations like integers and floats are allowed, while incorrect formats result in errors:

s.number().format("float").int(); // Error: incompatible format and type
s.number().int().format("double"); // Error: 'double' format not allowed for integers

Range Validation: Another feature of Release 0.8 was the introduction of automatic range checking. Developers can specify minimum and maximum values for numbers, and the system will throw an error if the value is out of range.

s.number().min(5).max(3); // Error: max cannot be smaller than min
s.number().min(1).max(10).const(15); // Error: constant is out of specified range

These enhancements helped prevent logical errors during schema definition and ensured more consistent data validation.

Other changes

Changeset Management with GitHub
Update pnpm version to 9.10.0
Meta Object Updates for meta method

Conclusion

The Release 0.9 and Release 0.8 updates significantly improve the developer experience by offering better examples, stricter validation, and enhanced error handling—especially for TypeScript users. These features make schema definition more intuitive, reliable, and easier to maintain in complex projects. Be sure to explore the new functionality to make your validation workflows more efficient!

Happy schema definition!

Link to the project: https://github.com/vitalics/ajv-ts

Forem: Vitali Haradkou

TypeScript knows your SQL is broken before your tests even run

The trick: SQL grammar as TypeScript types

What you actually get

How it connects to real queries

The Playwright fixture

The language server plugin

Quick recap

Try it

Testing Angular Components by Properties with Playwright

What Is It?

Installation

Setup

The angular= Selector Syntax

Operators

Nested Properties

Multiple Conditions (AND)

The $ng Fixture

Narrowing

Custom Matchers

Real-World Example

Requirements

Wrapping Up

Sending beautiful Playwright test reports via email using shadcn/ui and react-email

Why email reports?

New in this release: shadcn/ui templates

Template overview

Subpath exports

Quick setup

The templates

Previewing templates locally

Real Docker Containers in Playwright Tests — Zero Boilerplate

The problem with containers in Playwright today

The new way

Quick examples

Postgres with wait strategy

Multiple containers at once

Build from Dockerfile

Compose with your own fixtures

Custom matchers

Requirements

Stop Throwing Exceptions. Use Option and Result Instead.

There's a better model

Option — make absence impossible to ignore

Transform without unwrapping

Quick checks

Result — make errors part of the contract

Wrapping existing code that throws

Pattern matching

match — exhaustive two-branch dispatch

Globals — skip the imports

The real benefit

Install

Stop Leaking Resources: How to Use AbortSignal in Playwright Tests

The Problem: Zombie Requests After Test Timeouts

Why afterEach Does Not Solve This

Enter AbortSignal

Setting Up fixture-abort

Basic Usage: Cancellable Fetch

Pattern: Polling with Cooperative Cancellation

Pattern: Multiple Parallel Requests

Pattern: Manual Abort for Early Exit

Pattern: Abort Controller with Callback

Pattern: Signal with Timeout

Pattern: Passing Signal to Third-Party Libraries

Custom Expect Matchers

How It Works Under the Hood

Common Mistakes to Avoid

Getting Started

Introducing Playwright Labs: Best Practices as Code

What is Playwright Labs?

Video Overview

Why Playwright Labs?

The playwright-best-practices Package

1. Test Stability & Reliability (CRITICAL)

2. Test Execution Speed (CRITICAL)

3. Locator Best Practices (HIGH)

4. Assertions & Waiting (HIGH)

5. Parallel Execution (MEDIUM-HIGH)

6. Fixtures & Test Organization (MEDIUM)

The `angular=` Selector Syntax

The `$ng` Fixture

`match` — exhaustive two-branch dispatch

The Solution: `@rslike/std`

2. Option: No More `null` or `undefined`

`Result` & `Option` Constructors Control Flow

`Option.fromPromise` & `Option.fromAsync`