in `globalSetup`, wrong module version served in pnpm workspaces

[deyaaeldeen]

Describe the bug

When a pnpm workspace has multiple versions of the same dependency (e.g., @azure/core-lro@2.7.2 from a published npm package and @azure/core-lro@3.x from a workspace link), vitest serves the wrong version to some importers, causing:

SyntaxError: [vite] The requested module '@azure/core-lro' does not provide an export named 'deserializeState'

Root cause: The configEnvironment hook in vitest's VitestResolver plugin returns early for the __vitest__ environment (line: if (name === "__vitest_vm__" || name === "__vitest__") return;). This skips setting resolve.noExternal = true for the main test environment. Without this, Vite's import analysis plugin treats bare specifiers of node_modules packages as "external" and does not resolve them during transform, leaving raw bare specifiers in the transformed code.

This triggers a cascade of bugs:

1. Vite's createIsExternal caches externalization decisions by bare specifier (the processedIds map), ignoring the importer. Once @azure/core-lro is deemed external for one importer, ALL importers get the same result.
2. Vite's module runner caches modules by URL (urlToIdModuleMap). The bare specifier @azure/core-lro maps to whichever version was resolved first (2.7.2), and all subsequent importers get that cached module.
3. The { cache: true } protocol between client and server doesn't carry module identity. The server resolves the bare specifier to the correct version (3.x), sees it was already transformed, and returns { cache: true }. The client interprets this as "use what you have" and serves the wrong version (2.7.2).

Workaround: Add resolve.dedupe: ["@azure/core-lro"] to vitest.config.ts. This forces Vite's import analysis to resolve the bare specifier from the project root, producing a consistent /@fs/... URL that bypasses all three cache issues.

Reproduction

https://github.com/Azure/azure-sdk-for-js

git clone https://github.com/Azure/azure-sdk-for-js.git
cd azure-sdk-for-js
git checkout cd25924f9c263e012f50a447a770ac68d703d2a4
pnpm install
cd sdk/batch/batch
npx vitest run --no-coverage test/files.spec.ts

Expected: Tests pass (or fail for non-resolution reasons)
Actual: SyntaxError: The requested module '@azure/core-lro' does not provide an export named 'deserializeState'

Steps to reproduce

The dependency tree that triggers this:

• @azure/batch (test target) depends on:
  • @azure/arm-batch (workspace link) → @azure/core-lro workspace (3.x, has deserializeState)
  • @azure/arm-resources@5.2.0 (published npm) → @azure/core-lro@2.7.2 (no deserializeState)

The arm-resources package uses ESM syntax without "type": "module" in package.json, so vitest's shouldExternalize returns false for its files — they're transformed by Vite. During transform, Vite's import analysis encounters import { ... } from "@azure/core-lro":

1. shouldExternalize(environment, "@azure/core-lro", "arm-resources/deployments.js") → calls createIsExternal → resolves to 2.7.2 (in node_modules) → canExternalizeFile → true → bare specifier NOT resolved → cached in processedIds["@azure/core-lro"] = true
2. shouldExternalize(environment, "@azure/core-lro", "arm-batch/pollingHelpers.js") → processedIds.has("@azure/core-lro") → returns cached true → bare specifier NOT resolved (even though this importer should get 3.x)
3. Module runner receives __vite_ssr_import__("@azure/core-lro") from both importers → first resolution (2.7.2) cached in urlToIdModuleMap["@azure/core-lro"] → second importer gets stale 2.7.2 → crash

System Info

vitest/4.1.2 linux-x64 node-v22.22.1
vite/7.3.1
pnpm/10.33.0

Used Package Manager

pnpm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[hi-ogawa]

With the information, can you craft minimal reproduction?

[github-actions]

Hello @deyaaeldeen. Please provide a minimal reproduction using a GitHub repository or StackBlitz (you can also use examples). Issues marked with needs reproduction will be closed if they have no activity within 3 days.

[deyaaeldeen]

Minimal Reproduction

https://github.com/deyaaeldeen/vitest-processedids-cache-bug

pnpm install
cd packages/app
npx vitest run

Expected: All 3 tests pass
Actual: 2 tests fail — foo is undefined because my-lib v1 (which does not export foo) is loaded instead of v2

Root Cause Analysis

The bug is in Vite's import analysis plugin, specifically the processedIds cache in the createIsExternal function. This cache uses only the bare specifier as the key, ignoring the importer. When multiple versions of the same package exist in a monorepo (via pnpm workspace linking + non-workspace dependency), the first resolution determines the externalization decision for ALL importers.

Sequence

1. consumer/index.js (non-workspace, depends on my-lib v1) is transformed. shouldExternalize("my-lib") returns true because v1 resolves to node_modules. The result is cached: processedIds.set("my-lib", true).

2. The bare specifier "my-lib" is kept in the transformed output. The module runner loads v1 externally and stores it at URL "my-lib" in evaluatedModules.urlToIdModuleMap.

3. wrapper/index.js (workspace, depends on my-lib v2) is transformed. Its "my-lib" import hits the processedIds cache hit — returns true without re-resolving. The bare specifier is kept even though wrapper's my-lib should resolve to the workspace v2.

4. The module runner receives "my-lib" and finds the v1 module already cached at that URL → returns v1 instead of v2.

Key Conditions

• The __vitest__ Vite environment has noExternal: [] (empty array), which allows shouldExternalize to run and populate processedIds. The built-in ssr environment has noExternal: true (boolean), which short-circuits to always return false — hiding the bug. The reproduction uses a custom environment with viteEnvironment: "__vitest__" to expose this.

• The non-workspace package (consumer) must NOT have "type": "module" in its package.json, so its .js file with ESM syntax goes through Vite transform (rather than native Node loading), triggering the import analysis that populates processedIds.

Relevant Vite Code

• createIsExternal / processedIds cache: packages/vite/src/node/ssr/ssrExternal.ts
• The fix would need to include the importer (or its resolution context) in the cache key.