Code Smells / Technical Debt
With the release of Stencil 4.43 (and refined in subsequent versions), a new Vitest-based test runner was introduced. The current Jest-based runner is marked for deprecation in the upcoming major version of Stencil.
Currently, our test suite relies on the legacy Jest integration. Staying on the legacy runner will prevent us from upgrading to future Stencil versions and misses out on the performance benefits and modern API support provided by Vitest. However, initial testing on ino-control-item suggests that the new runner still exhibits some instabilities, making a "big bang" migration risky for our CI stability.
Proposed Technical Approach
We will adopt a hybrid testing strategy to migrate packages/elements incrementally.
Infrastructure Setup
File Naming Convention
- Keep existing legacy tests as
*.spec.ts (Jest).
- Implement new or migrated tests as
*.vitest-spec.ts. This allows the runners to target specific files without overlap.
Incremental Migration Steps
- Finalize the migration for
ino-control-item as the first official component on Vitest.
- All newly created components must use the
.vitest-spec.ts format.
- Whenever an existing component requires significant logic changes or has a failing Jest test (as seen with
ino-control-item), that component's suite should be migrated to Vitest.
Compatibility Mapping
- Follow the Stencil Vitest Migration Guide.
- Replace
newSpecPage and newE2EPage with the updated Vitest testing utilities.
- Update matchers from
jest globals to vitest assertions.
Additional Context
Code Smells / Technical Debt
With the release of Stencil 4.43 (and refined in subsequent versions), a new Vitest-based test runner was introduced. The current Jest-based runner is marked for deprecation in the upcoming major version of Stencil.
Currently, our test suite relies on the legacy Jest integration. Staying on the legacy runner will prevent us from upgrading to future Stencil versions and misses out on the performance benefits and modern API support provided by Vitest. However, initial testing on
ino-control-itemsuggests that the new runner still exhibits some instabilities, making a "big bang" migration risky for our CI stability.Proposed Technical Approach
We will adopt a hybrid testing strategy to migrate
packages/elementsincrementally.Infrastructure Setup
@stencil/vitestandvitestinto thepackages/elementsworkspace.stencil.config.tsto support the Vitest output target/testing configuration.package.jsonscripts to support running both Jest and Vitest suites.File Naming Convention
*.spec.ts(Jest).*.vitest-spec.ts. This allows the runners to target specific files without overlap.Incremental Migration Steps
ino-control-itemas the first official component on Vitest..vitest-spec.tsformat.ino-control-item), that component's suite should be migrated to Vitest.Compatibility Mapping
newSpecPageandnewE2EPagewith the updated Vitest testing utilities.jestglobals tovitestassertions.Additional Context