Skip to content

charlie: vitest #1974

@shellscape

Description

@shellscape

The goal of this issue is to migrate all Ava tests in the repository to Vitest.

Phase 1 — low-complexity packages (mechanical conversions)

  • packages/beep
  • packages/buble
  • packages/data-uri
  • packages/dsv
  • packages/eslint
  • packages/graphql
  • packages/image
  • packages/inject
  • packages/legacy
  • packages/multi-entry
  • packages/strip
  • packages/sucrase
  • packages/swc
  • packages/virtual
  • packages/yaml

Phase 2 — medium complexity (snapshot/serial heavy)

  • packages/babel
  • packages/dynamic-import-vars
  • packages/esm-shim
  • packages/html
  • packages/json
  • packages/replace
  • packages/terser
  • packages/url
  • packages/wasm

Phase 3 — medium complexity (environment/lifecycle sensitive)

  • packages/auto-install
  • packages/pluginutils
  • packages/run

Phase 4 — high complexity (largest fixture matrices)

  • packages/node-resolve
  • packages/commonjs
  • packages/typescript

Constraints for each phase

  1. Perform a straight Ava → Vitest migration only (no compatibility layer).
  2. Convert tests/assertions file-by-file, replacing Ava patterns/builtins with Vitest patterns/builtins.
  3. Do not modify test logic or the shape/intent of what is being tested.
  4. Keep changes succinct and clean (no over-engineered supporting abstractions).
  5. Update repository configuration as needed during migration (including root package.json and package-level test config/scripts where required).
  6. Before PR readiness, inspect .github/workflows and run all required checks; CI must be passing.
  7. Fix any migration-introduced failures before considering the work mergable.
  8. This plan intentionally avoids the previously closed approach from chore(repo): migration from ava to vitest. phase 1 #1972.
  9. Treat packages/alias as canonical template.
  10. Lock a single Vitest invocation pattern per package (using .config/vitest.config.mts).
  11. Confirm snapshot path parity and CI behavior before batch migrations.
  12. This repository uses conventional commit format. Each commit should be in that format. The PR title for each phase should be in the format chore(repo): test migration to vitest. phase {phaseNumber}
  13. If you think you have to add dependencies at any point, push what you have, open the PR, and ask questions about adding the dependency(s) before doing so

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions