is it possible to load a different tsconfig for Vitest? I could do it with ts-jest

[ghiscoding]

So as the tittle suggest, the question is to ask if it's possible to load a different tsconfig file? Like a tsconfig.spec.json where I could add the paths of my spec files. The problem that I currently have is that I only have 1 tsconfig file for both my Vue+Vite / Vitest project and I don't want, neither need, to transpile the unit test spec files.

I know that most boilerplate, like Vitesse for example, would have all their unit tests in a separate \test folder in the root but I don't like this structure, I prefer to have my unit tests close to the components/services in a __tests__ which I could do easily in Jest

In Jest I was able to do load a different tsconfig via ts-jest with this config,

// jest.config.js
module.exports = {
  rootDir: '../',
  globals: {
    'ts-jest': {
      // ... other options
      tsconfig: '<rootDir>/test/tsconfig.spec.json', // <-- custom tsconfig specific for Jest
    },
  },
}

is that possible in Vitest? I couldn't find anything in the docs neither in any issues//discussions.

I want to have 2 tsconfig, where the base one would be similar to this

{
  "compilerOptions": {
    "target": "es2020",
    "module": "esnext",
    "baseUrl": ".",
    "types": ["node", "quasar", "vite", "vite/client"],
    "lib": ["esnext", "dom", "dom.iterable", "scripthost"]
  },
  "include": ["src/**/*.ts", "src/**/*.vue", "src/**/*.spec.ts"],
  "exclude": ["node_modules", "src/**/*.spec.ts"]
}

and a separate one for Vitest that would look like this

{
  "extends": "./tsconfig.base.json",
  "compilerOptions": {
    "types": ["vitest/globals"],
  },
  "include": ["src/**/*.spec.ts"]
}

How can I do this in Vitest? I want to keep current structure of __tests__ close to their source...

[AdamCoulterOz]

TL;DR: There’s no Vitest equivalent to ts-jest.tsconfig. Vitest runs inside Vite, and Vite doesn’t support switching tsconfigs at runtime. Use one runtime tsconfig (Vite + Vitest) and separate build/typecheck configs instead.

---

I ran into this exact question coming from a Jest + ts-jest background, and I think your expectation here is completely reasonable.

What you're describing "having app code and test code typechecked/compiled under different tsconfig rules (even when tests are colocated in __tests__)" is exactly how Jest works. In Jest, the test runner owns the TypeScript pipeline, so it can explicitly say use this tsconfig just for tests. There's nothing wrong with that mental model.

The surprise with Vitest isn't that the use-case is invalid, but that Vitest doesn't own TypeScript compilation at all.

The key realisation for me was: Vite ≠ Vitest.

Vitest is not a standalone test runner in the same way Jest is. Vitest runs on top of Vite, and Vite is the thing that owns:

• module resolution
• transforms (via esbuild)
• plugins
• runtime modes

Vitest simply asks Vite to execute files in mode: test.

Because of that:

• Vitest has no tsconfig option of its own
• there is no Vitest equivalent of ts-jest.tsconfig
• TypeScript handling is inherited from Vite

Even though Vitest supports vite.config.ts, vitest.config.ts, config merging, conditional config via mode/VITEST, etc., all of those are still Vite configs. None of them allow selecting a different tsconfig.json.

This is also why options like esbuild.tsconfigRaw don't really solve the problem. tsconfigRaw is an esbuild escape hatch that lets you inline or override some compilerOptions, but it does not:

• create a separate TypeScript program
• change include/exclude semantics
• replace tsconfig resolution
• behave like tsc -p someconfig.json

Only a subset of tsconfig options are respected by esbuild, and Vite will still resolve the project tsconfig implicitly for plugins, path resolution, and tooling. Using tsconfigRaw as a "tsconfig switch" is therefore incomplete and brittle, and not equivalent to ts-jest.

Regarding this part of your concern:

"I don't want, neither need, to transpile the unit test spec files."

That makes perfect sense from an app build perspective. In the Vite/Vitest model, test files are still transpiled on demand by the runtime when tests run, not included in your application build or tsc output.

The supported pattern in Vite/Vitest is therefore:

• One runtime tsconfig used by Vite (and Vitest)
• Separate build / typecheck tsconfigs if needed (e.g. excluding *.spec.ts from app builds)
• Tests can remain colocated in __tests__ (location is not the issue)

Example setup you might use:

tsconfig.json - runtime (Vite + Vitest)

This is the one both Vite and Vitest use.

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "baseUrl": ".",
    "types": [
      "vite/client",
      "vitest/globals"
    ],
    "lib": ["ESNext", "DOM"]
  },
  "include": ["src"]
}

tsconfig.build.json - app build & typecheck

This is what you use with tsc -p tsconfig.build.json or your build tool.

{
  "extends": "./tsconfig.json",
  "exclude": [
    "**/__tests__/**",
	"**/*.spec.ts"
  ]
}

This removes test files from your app build and typechecking, while still allowing them to be colocated.

vite.config.ts - app runtime

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
export default defineConfig({
  plugins: [vue()],
})

No tsconfig override needed here.

vitest.config.ts - test runner config (optional)

import { defineConfig } from "vitest/config";
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  test: {
	globals: true,
	environment: 'jsdom',
  },
})

In other words, adopting Vitest isn't just "swapping Jest for Vitest", it's effectively replatforming your build to Vite, where TypeScript is treated as ambient project metadata rather than a per-invocation input. Once that distinction clicks, the limitation makes sense, even if it's a bit surprising coming from Jest.

Hopefully this saves someone else the same round trip.