void-testing-server-modules

Aliases server-only and client-only packages to empty stubs in Vitest configs.

Updated May 29, 2026
One-click install
npx skills add https://github.com/voidcorp-core/void-harness --skill void-testing-server-modules-voidcorp-core
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: void-testing-server-modules
Source: https://github.com/voidcorp-core/void-harness/tree/main/packages/cli/core-assets/packs/pack-server/skills/void-testing-server-modules
Command: npx skills add https://github.com/voidcorp-core/void-harness --skill void-testing-server-modules-voidcorp-core

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Vitest runs outside both the RSC server graph and the browser, so importing any module whose chain reaches server-only or client-only crashes the entire test run with a cryptic error before a single assertion executes. This Skill shows how to neutralize those import-time tripwires at test time without weakening the real build-time boundary. ## Core Features & Use Cases - Shared Vitest alias configuration: Maps server-only and client-only to a single empty stub module via test.alias in a shared vitest.base config that every package in a monorepo extends. - Boundary preservation guidance: Explains what the alias does and does not buy you, so test-time convenience never papers over a genuine client/server boundary violation. - Use Case: A Next.js monorepo's Vitest run fails on import with "This module cannot be imported from a Client Component module". Add the alias once in the shared config, then unit-test the pure logic inside server modules without standing up an RSC runtime. ## Quick Start Ask the agent to configure the shared Vitest config so server-only and client-only imports are aliased to an empty stub for unit tests.

Frequently Asked Questions about void-testing-server-modules

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix Vitest crashing on server-only imports?

Alias `server-only` and `client-only` to an empty stub module using `test.alias` in your Vitest config. The tripwire's only job is to throw outside its runtime, so an empty module is the correct test-time substitute, not a mock.

How to unit test Next.js server components logic with Vitest?

Keep the pure, testable logic in a runtime-agnostic services module and let a thin server wrapper carry the `server-only` import. Then alias the tripwire packages to an empty stub in the shared Vitest config to test that logic directly.

Should I mock server-only with a partial implementation in tests?

No. `server-only` has no API to mock, only a side effect to neutralize, so the only correct substitute is an empty module. Define the alias once in the shared config rather than scattering it per test file.

Does the Vitest alias weaken the server/client boundary?

No, the alias is test-only and the real boundary still holds at build time. If a client component genuinely imports a server module, the build will correctly reject it; never widen the alias to hide a true violation.

When should I not stub server-only in tests?

Do not stub it in integration or e2e runners like Playwright or the Next.js test runtime that execute in the real runtime, where the tripwire is meaningful. Pure modules with no `server-only` import need no alias at all.