# @zuplo/test

Type definitions for the test constructs (`describe`, `it`, `beforeEach`, …) and
the `TestHelper` object that `@zuplo/cli` injects when it runs a Zuplo project's
tests. There is no runtime code here — the implementation is generated by the
CLI — so `dist/index.d.ts` is hand-maintained rather than compiled.

This package was moved here from the standalone `zuplo/test` repository.

## Releasing

`@zuplo/test` is **not** published as part of a core release. It has its own tag
prefix (`test-v`) and its own workflow, so a version only goes out when someone
asks for one:

1. Run the **Run Release** workflow and pick `@zuplo/test` as the product.
2. That computes and pushes the next `test-v<major>.<minor>.<patch>` tag.
3. Pushing the tag runs
   [`release-test.yaml`](../../.github/workflows/release-test.yaml), which
   publishes to npmjs.com and GitHub Packages and cuts a GitHub release.

The `version` field below is informational — the release workflow overwrites it
with the version from the tag before publishing. Because there are no existing
`test-v*` tags yet, the first release seeds its version from that field.

Consequences of being outside the core release:

- `packages/test` is excluded from the npm workspaces list, so `@zuplo/test`
  still resolves from the registry for local development and CI type-checking.
  Editing `dist/index.d.ts` here does not change what `npm ci` installs until a
  release goes out.
- `scripts/set-versions.mjs` skips this directory so core releases don't
  overwrite the version.
- After releasing a new version, bump the `@zuplo/test` pin in
  [`packages/zuplo/package.json`](../zuplo/package.json) (and refresh the
  lockfile) if the meta-package should ship the new types.