
migrate-to-rstest
Migrate Jest, Vitest, or Playwright Test to Rstest while preserving test discovery, assertions, mocks, snapshots, and coverage.
- Installs
- 424
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/rstackjs/agent-skills --skill migrate-to-rstest- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads migrate-to-rstest automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Migrate to Rstest
Goal
Migrate the smallest runnable Jest, Vitest, or Playwright Test scope with minimal behavior change. Use documentation and types that match the installed Rstest version; use latest online docs only after the capability gate confirms they apply.
Workflow
- Detect the runner, environment, Rstack integration, and smallest runnable scope with
references/detect-test-framework.md. - Run
references/dependency-install-gate.mdbefore choosing Rstest, coverage, adapter, or plugin APIs. - Before editing, record the exact command, Node and runner versions, environment, files/tests/skips/snapshots, and failures. Capture the pre-migration test manifest and follow
references/discovery-parity.mdthroughout the migration. - For Jest read
references/jest-migration-deltas.md; for Vitest readreferences/vitest-migration-deltas.md; for global APIs also readreferences/global-api-migration.md; for a detected Playwright Test runner readreferences/playwright-migration-deltas.md. Do not load the Playwright path for a browser-only request whose runner is not Playwright Test. Migrate scripts, config, and setup before editing test bodies; prefer adapter or Rsbuild/Rspack fixes over broad test rewrites. - If config loading emits
[MODULE_TYPELESS_PACKAGE_JSON], usereferences/config-module-type.md. Do not suppress the warning or change the whole package module type without an audit. - Get the migrated scope semantically green. Fix failures in this order: dependency skew, config/resolver, discovery, setup/environment/coverage, mocks/timers/snapshots, then test bodies.
- Compare the post-migration manifest and execution counts with the baseline. Classify every added, removed, skipped, or excluded test explicitly; do not call a run equivalent merely because it is green. For Jest snapshot migrations, also complete the snapshot cleanup and
uncheckedvalidation inreferences/jest-migration-deltas.md. - Remove temporary aliases, diagnostic hooks, and copied legacy workarounds that are no longer required. Keep only configuration proven necessary by behavior or measurement.
- If wall time, build, test runtime, logs, or memory materially regress, load and follow the
rstest-debuggingskill when available. Otherwise use the migration fallback inreferences/performance-diagnosis.md, then readreferences/dependency-bundling-performance.mdand/orreferences/mocked-module-build-graph.mdaccording to the measured bottleneck. Change one variable at a time. - After correctness and performance validation, remove only legacy files and dependencies owned by the migrated scope. Summarize behavior parity, discovery differences, unsupported fields, retained compatibility config, performance tradeoffs, and TODOs.
Guardrails
- Keep the smallest viable scope. Do not broaden a monorepo migration because scopes share a lockfile.
- Do not change production behavior, assertions, test names, scenarios, coverage thresholds, or ignore directives to make migration pass.
- Do not introduce
jest/vishims or aliases; rewrite call sites withreferences/global-api-migration.md. - Do not silently drop unknown config fields or historical excludes. Verify, replace, or report each one.
- Do not compare performance across different test manifests, Node versions, coverage modes, cache states, or worker settings.
- Keep the previous runner until Rstest is green. Use a local Rstest checkout only for labeled diagnostics, then validate the final result with the project's installed dependency.
- Escalate before many test edits or any production-source change: report why smaller config/setup fixes failed, options, risks, and the recommended path.
High-risk Rstest deltas
rstest/rstest runis single-run; watch mode isrstest --watchorrstest watch.globalsdefaults tofalse; preserving global APIs requiresglobals: trueand@rstest/core/globalstypes.- Rstest builds before tests run.
rs.mock()is runtime replacement and does not by itself prune the real module graph. - Dependency bundling trades compiler work for runtime Node loading. Neither “bundle all” nor “externalize all” is universally faster; measure a representative file and the full scope.
- An externalized runtime mock must match the exact request and module format. A config-wide external is unsafe when any test needs the real module.
FAQ
What does the migrate-to-rstest skill do?
Migrate Jest, Vitest, or Playwright Test to Rstest while preserving test discovery, assertions, mocks, snapshots, and coverage.
How do I install migrate-to-rstest?
Run npx skills add https://github.com/rstackjs/agent-skills --skill migrate-to-rstest in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/migrate-to-rstest/ (personal) or .claude/skills/migrate-to-rstest/ (project).
Which AI agents can use migrate-to-rstest?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is migrate-to-rstest safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains migrate-to-rstest?
It is published by rstackjs in rstackjs/agent-skills. It has 424 recorded installs.
More from rstackjs/agent-skills
rsbuild-best-practices
rstackjs/agent-skills
Configure, review, or troubleshoot Rsbuild applications, including build/dev commands, assets, type checking, and bundle optimization.
rstest-best-practices
rstackjs/agent-skills
Set up, write, or review Rstest tests and configuration, including environments, mocks, snapshots, coverage, and CI.
rslib-best-practices
rstackjs/agent-skills
Configure, review, or troubleshoot Rslib library builds, output formats, declarations, dependency handling, and integrations.
rspack-best-practices
rstackjs/agent-skills
Configure, review, or troubleshoot Rspack builds, including loaders, CSS, assets, type checking, bundle optimization, and profiling.
rspress-best-practices
rstackjs/agent-skills
Configure, review, or troubleshoot Rspress v2 sites, including content conventions, navigation, MDX, assets, search, and deployment.
rspack-v2-upgrade
rstackjs/agent-skills
Use when upgrading a Rspack 1.x project to v2, including dependency and configuration updates.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work