Tests fail after updating from Vitest 4.0.15 to 4.0.16 — module resolution issue

[Arsync]

Hello! 👋

We’re running into an issue after Renovate opened a PR to update Vitest from 4.0.15 to 4.0.16. While our test suite passes on 4.0.15, it fails on 4.0.16+ with the following error:

Error: ENOTDIR: not a directory, open '/home/runner/work/core/core/packages/mirta-basics/src/index.ts/array'

We’re using a monorepo setup with TypeScript path mappings ("paths" in tsconfig.json), and our Vitest config explicitly defines aliases based on discovered packages to support development before build (link to config).

Interestingly, this works perfectly in 4.0.15, but breaks in 4.0.16 without any changes to the config or codebase.

Could this be related to internal changes in module resolution or Vite's import handling?
Is there something we need to adjust in our config to maintain compatibility?

❌ Failing CI run: link
✅ Link to changes: link
📁 Monorepo structure: @mirta/* packages with src/ as source, aliased via resolve.alias

exports in @mirta/basics like

"exports": {
    ".": {
      "import": {
        "types": "./dist/index.d.mts",
        "default": "./dist/index.mjs"
      }
    },
    "./array": {
      "import": {
        "types": "./dist/array/index.d.mts",
        "default": "./dist/array/index.mjs"
      }
    }
}

Thank you in advance!

[Arsync]

After investigation, I realized that pointing an alias directly to a file (like index.ts) while expecting subpath resolution (/array) is technically incorrect.

resolve: {
  alias: packages.reduce<Record<string, string>>((items, nextItem) => {
    items[nextItem.name] = nodePath.join(rootDir, nextItem.workspacePath, 'src', 'index.ts')
    return items
  }, {}),
},

The proper setup should alias to the directory:

'@mirta/basics': '/path/to/packages/mirta-basics/src' // ← directory, not file

So this appears to be a tightening of module resolution logic in 4.0.16, which no longer tolerates this case.

This is likely not a bug, but a correctness improvement.

Still, it might be worth documenting or warning users during startup if an alias ends with a file but is used with subpaths — since this could help others migrate smoothly.

Thanks for all your work on Vitest! 🙌