setupFiles does not import npm module correctly in mono repo project setup

[gb-jos]

Describe the bug

I have a mono repo project, where I am trying to use vitest to test one of the monorepo packages. I need some polyfills in the environment and I am trying to loading this using setupFiles and mentioning the npm package name there. As far as I have read the configuration documentation, this should work. But unfortunately it fails.

Seemingly the problem is with the path resolution, the path seems to have been resolved correctly, but then root is prefixed on this absolute path. Find attached screenshot from shared reproduction stackblitz

Reproduction

stackblitz minimal repro

1. Run npm run test in packages/package.
2. Notice the error message regarding failing to import the reflect-metadata module

System Info

latest vite and vitest

Used Package Manager

npm

Validations

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

[gb-jos]

cc @sheremet-va

[sun0day]

Seems the problem happens here.

https://github.com/vitest-dev/vitest/blob/95da4d66933db46da368d5d66f422afd26fba4c1/packages/vite-node/src/utils.ts#L77-L84

Isn't it weird resolve(root, id.slice(1) when id is an abolute path @sheremet-va

[gb-jos]

@sun0day I can confirm that in my case the problem happens here.

its a monorepo, the tests are running inside lambda-logger package, and the reflect-metadata is hoisted to root node_modules folder. I guess this will only happen in monorepo setup, as otherwise id.startsWith(root) will be true.

[PatrickChen928]

I think this issue may solve by setting

{
test: {
  // `vitest` use the outside dir as root, different from `vite`
  root: resolve(__dirname, "../../")
}
}

But now there are two problems:

1. test.root is not effective. See #2050.
2. vite-node still use vite.root. See below: https://github.com/vitest-dev/vitest/blob/5b8d6dbe75222aeeee897a3129222818c010bdd8/packages/vite-node/src/server.ts#L121

For fix problem two, could solve by use this.options.root.

But I'm not sure if this would cause other problems.

[gb-jos]

@ChpShy I would consider that as a hack rather than a solution, as even though it would solve the resolution, it would also cause vitest to include all tests from other projects in the monorepo.

A better hack (which I am using right now) is to create a local file inside the project, that internally imports the dependency, and use that in the setupFiles instead of the dependency directly.

[mc-petry]

Also, this behavior works in monorepo as expected with older version 0.23.4. This issue prevents me from updating to the latest version.

[sheremet-va]

This should actually be fixed I think. Can you confirm it doesn’t work with the latest version?

[mc-petry]

It's not fixed yet (or not fully fixed). I have monorepo with packages:

• @repo/app
• @repo/testing

@repo/testing contains setup file:

import { vi } from 'vitest'

console.log('init')
vi.mock('framer-motion', async () => {
  console.log('mock')
  const framer = await vi.importActual<object>('framer-motion')

  return {
    ...framer,
    AnimatePresence: ({ children }: { children: React.ReactNode }) => children,
  }
})

In package @repo/app i use setup file from @repo/testing.

Actual console.log for v0.23.4:

stdout | unknown test
init

stdout | unknown test
mock

Actual console.log for v0.25.3:

stdout | unknown test
init

So in fact for 0.25.3 file is imported but vi.mock not working.

[sheremet-va]

So in fact for 0.25.3 file is imported but vi.mock not working.

So how is this related to this issue? This issue is specifically about importing setupFile, but in your example mock is not called. If you have a different problem, please create a separate issue, if it doesn't already exist.

I ran reproduction from this issue with the latest version and it's working fine, so I'm closing this issue.