Skip to content

fix(vitest-environment): avoid vitest/environments import warning in vitest4.1#1627

Open
yamachi4416 wants to merge 3 commits intonuxt:mainfrom
yamachi4416:avoid-vitest-environment-warn
Open

fix(vitest-environment): avoid vitest/environments import warning in vitest4.1#1627
yamachi4416 wants to merge 3 commits intonuxt:mainfrom
yamachi4416:avoid-vitest-environment-warn

Conversation

@yamachi4416
Copy link
Collaborator

@yamachi4416 yamachi4416 commented Mar 20, 2026

🔗 Linked issue

📚 Description

the following warning appeared when importing vitest/environments in Vitest 4.1

Importing from "vitest/environments" is deprecated since Vitest 4.1. Please use "vitest/runtime" instead.

@pkg-pr-new
Copy link

pkg-pr-new bot commented Mar 20, 2026

Open in StackBlitz

npm i https://pkg.pr.new/nuxt/test-utils/@nuxt/test-utils@1627
npm i https://pkg.pr.new/nuxt/test-utils/vitest-environment-nuxt@1627

commit: 8c8338f

@yamachi4416 yamachi4416 marked this pull request as ready for review March 23, 2026 13:15
@yamachi4416 yamachi4416 requested a review from danielroe as a code owner March 23, 2026 13:15
@coderabbitai
Copy link

coderabbitai bot commented Mar 23, 2026

📝 Walkthrough

Walkthrough

The src/environments/vitest/index.ts file was modified to dynamically load the populateGlobal function instead of statically importing it from vitest/environments. A new async helper function importVitestEnvironments() was introduced that attempts to resolve and import vitest/runtime first, with a fallback to vitest/environments if resolution fails. The setup() function now awaits this helper and destructures populateGlobal from the resulting module. All other environment initialization and teardown logic remains unchanged.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and specifically describes the main change: fixing a vitest/environments import warning in vitest 4.1 by using vitest/runtime instead.
Description check ✅ Passed The description documents the deprecation warning from Vitest 4.1 and explains the motivation for the change, directly related to the changeset's objective.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
src/environments/vitest/index.ts (1)

70-74: Consider caching module selection once at module scope.

resolveModulePath(..., { try: true }) is currently re-evaluated per setup call. Caching this once avoids repeated sync resolution work.

♻️ Proposed refactor
+const vitestEnvironmentPkg =
+  resolveModulePath('vitest/runtime', { try: true }) ? 'vitest/runtime' : 'vitest/environments'
+
 // This can be removed when dropping support for vitest 4.0.x (We can static import from 'vitest/runtime')
 async function importVitestEnvironments() {
-  const pkg = resolveModulePath('vitest/runtime', { try: true }) ? 'vitest/runtime' : 'vitest/environments'
-  return await import(pkg) as typeof import('vitest/environments')
+  return await import(vitestEnvironmentPkg) as typeof import('vitest/environments')
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/environments/vitest/index.ts` around lines 70 - 74, The call to
resolveModulePath inside importVitestEnvironments is being re-evaluated on every
setup call; cache the chosen package name at module scope so resolution runs
once. Add a top-level const (e.g., vitestEnvPkg) that computes
resolveModulePath('vitest/runtime', { try: true }) ? 'vitest/runtime' :
'vitest/environments' and then update importVitestEnvironments to simply import
that cached vitestEnvPkg; keep the return typing as typeof
import('vitest/environments').
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/environments/vitest/index.ts`:
- Around line 70-74: The call to resolveModulePath inside
importVitestEnvironments is being re-evaluated on every setup call; cache the
chosen package name at module scope so resolution runs once. Add a top-level
const (e.g., vitestEnvPkg) that computes resolveModulePath('vitest/runtime', {
try: true }) ? 'vitest/runtime' : 'vitest/environments' and then update
importVitestEnvironments to simply import that cached vitestEnvPkg; keep the
return typing as typeof import('vitest/environments').

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: e6bf591f-a319-4053-af40-07af3bf1e9c4

📥 Commits

Reviewing files that changed from the base of the PR and between 5cbc6bb and 8c8338f.

📒 Files selected for processing (1)
  • src/environments/vitest/index.ts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant