How WildflowerJS Is Tested

The suite

447 test files run under Vitest browser mode, driven through Playwright, against the built distribution files rather than the source. There is no jsdom in the pipeline.

The build is where behaviour can change. Minification renames properties through a hand-maintained allowlist and strips the development diagnostics, so a pass against source proves less than a pass against the file a page will download.

Why 21 bundles

Seven tiers ship, from nano to full, and each is a different bundle. Lists are absent from nano, the frame loop ships only with pools, and queries and routing exist in some tiers and not others. A feature can work in the tier you tested and be missing from the one a reader downloads.

Every tier is therefore built three ways. The dev build keeps the diagnostics, raw is unminified production code, and min is minified with property mangling. Each of the 21 lanes runs in its own browser against its own file. Tests that need an absent feature skip, which is why 5,419 run against full-dev and 2,011 against nano-min.

What runs when

Chromium runs all 21 lanes after every change to the framework, whether feature, fix or update, before the change is committed.

Firefox runs the same 21 lanes before every release. Its scheduling differs enough to surface races Chromium under-samples.

Continuous integration in the package repository runs eight tier lanes on every push. Safari is covered only by runs a maintainer starts by hand.

Checks that are not tests

Some failures never reach an assertion, so they have their own gates, each added after something shipped past it.

• Documented sizes. Every bundle size printed in the docs is compared with the compressed file, and the check lists each figure that has drifted.
• Typings. The published declarations compile under strict against fixtures with negative cases, so a declaration that accepts too much fails.
• Diagnostic ledger. Every error code and diagnostic test is cross-referenced against a ledger, so none can change without the reference page following.
• Pipeline parity. Before a tag, the package repository's own build scripts are compared with the framework's, the package is built with them, and the bundles are compared byte for byte with the ones the matrix tested.

Supply chain

Building the framework runs no npm install. The toolchain is three tarballs, rollup, terser and acorn, fetched once and verified against pinned SHA-512 hashes. Publishing is tag-triggered through trusted publishing, with no npm token in the pipeline, signed provenance generated on publish, and the attestation verified afterwards. Provenance establishes which workflow produced the published bytes and nothing about the correctness of the code they were built from.