vitest-dev / vitest-dev/vitest

Native runner manual mocks drop exports re-exported with export *

Open
#11,297 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
17.1k
Forks
2k
Avg merge
1d 22h
Merged PRs (30d)
94

Description

Describe the bug

With experimental.viteModuleRunner: false, a manual mock of a module that re-exports with export * loses the re-exported names.

// base.ts
export function fromBase() { return 'base' }

// star.ts
export * from './base.ts'
export function own() { return 'own' }

// star.test.ts
import { fromBase, own } from './star.ts'
vi.mock(import('./star.ts'), () => ({
  own: () => 'mocked-own',
  fromBase: () => 'mocked-base',
}))

test('x', () => {
  expect(own()).toBe('mocked-own')      // ok
  expect(fromBase()).toBe('mocked-base') // TypeError: fromBase is not a function
})

stderr:

[module mocking] Failed to parse './base.ts' imported from .../star.ts: TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
Cause

packages/mocker/src/node/parsers.ts, in parseModule: while collecting exports of the export * target, resolveModuleFormat(resolvedModulePath, code) is passed a filesystem path, but resolveModuleFormat(url, code) hands it to findPackageJSON, which requires a file: URL and throws. The re-export is then dropped.

Same function also warns Cannot process '...' because of unknown file extension for every non-JSON file, because the else branch runs for any extension that is not .json, including .ts and .js.

Reproduction

The three files above, experimental.viteModuleRunner: false in the config, npx vitest run.

System Info
vitest 5.0.1
node 22.18.0
win32 x64
Used Package Manager

npm

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
  • Check that this is a concrete bug
  • The provided reproduction is a minimal reproducible example of the bug

I have a one-line fix with a fixture test on a branch. I'll open the PR once #11295 is resolved, since outside contributors get one open PR at a time. Claude helped me find and verify this.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in packages/mocker/src/node/parsers.ts, at parseModule and its export-star handling; compare the filesystem-path and URL inputs used by resolveModuleFormat. Run the three-file reproduction with experimental.viteModuleRunner: false and npx vitest run, then add or run the fixture test to confirm both re-exported and local mocked names work without the parsing warning.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, typescript
Domain
testing-qa
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.