vite.config.ts should resolve alias from compilerOptions.paths in tsconfig.json

[FreeJ1nG]

Description

Some plugin configurations require a complex object that might be split across the codebase
For instance, CRXJS Vite Plugin requires a manifest.json file, which might/might not require an (possible aliased) import from another file

Reproduction link here

Right now, vite does not resolve alias paths within vite.config.ts or it's dependencies

- src/
  - some-other-module/
    - foo.ts
  - config/
    - index.ts
- vite.config.ts
- tsconfig.json

Example of such case:

// src/config/index.ts
// throws an error even when tsconfig.json defines compilerOptions.paths properly
import { Something } from "@/some-other-module/foo"; 

...

// vite.config.ts
import { someConfig } from "./src/config";
...

Example of another case:

// vite.config.ts
// throws an error even when tsconfig.json defines compilerOptions.paths properly
import { someConfig } from "@/config";
...

Both cases will throw error when running an instance of the vite server

Suggested solution

Maybe consider using compilerOptions.paths to resolve the imports in vite.config.ts somewhere in the plugin pipeline

Alternative

I'm also considering creating a plugin that creates a workaround, still not 100% sure on how to accomplish this though

Additional context

I've received quite a bit of concern and confusion regarding consumers of vite not being able to utilize aliases in vite.config.ts, and I believe it'd be an issue worth looking at

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[stackblitz]

Start a new pull request in StackBlitz Codeflow.

• vitejs-vite-aupdcb (Open reproduction)

[bluwy]

Currently, TS source code doesn't resolve aliases from compilerOptions.paths too. If we do in the config, it'd need to align with the source code. But the discussions about that are at #6828, and at the moment we don't plan to support it. (However, there's still debate within the team if this is something we actually want)

[FreeJ1nG]

If we do in the config, it'd need to align with the source code

What does this mean again?

[bluwy]

If tsconfig alias would work in a config file, it should also work in your source code files for consistency.

[FreeJ1nG]

If tsconfig alias would work in a config file, it should also work in your source code files for consistency.

But technically it does work if resolve.alias is added right?

i feel like support for tsconfig paths in vite.config.ts is a different issue that currently doesn't have an easy workaround? (cmiiw)

[FreeJ1nG]

However, there's still debate within the team if this is something we actually want

What is the consideration for the vite team to add/not add this feature?

[aelbore]

i dont know if this work, but what about execute the vite.config.{ts,js} with esbuild-register or swc-register or maybe ts-node?

[FreeJ1nG]

i dont know if this work, but what about execute the vite.config.{ts,js} with esbuild-register or swc-register or maybe ts-node?

The vite config is usually used by vite's server, e.g. executing vite (dev server) or vite build, so it's probably not viable to use ts-node since it's we're not trying to run vite.config.ts in isolation

Unless you mean transpiling vite.config.ts to resolve it's paths first, but that also has it's own problems like files not getting run through the vite plugin pipeline, etc.

CMIIW

[bluwy]

But technically it does work if resolve.alias is added right?

Yes, but resolve.alias has different resolve behaviour compared to tsconfig paths. Tsconfig paths is more lax and could map to more paths than intended, but will still cover the resolve.alias behaviour. If we support tsconfig paths in the config, we're supporting more than what resolve.alias covers.

i feel like support for tsconfig paths in vite.config.ts is a different issue that currently doesn't have an easy workaround? (cmiiw)

I think you can still use relative imports?

What is the consideration for the vite team to add/not add this feature?

There's still mixed opinions about this. My opinion is https://x.com/robpalmer2/status/1770612164396515667 and the result in #6828 (comment). Others think that supporting tsconfig alias would be convenient and rustifying the resolver would solve the performance issue, and that vite-tsconfig-paths had millions of downloads per month (people want it).

[nckirik]

having this ability would be great, especially in a nx monorepo.

i usually need to call certain functions in from other packages in the vite.config.ts

[bluwy]

Closing this as it's something we don't plan on supporting for now.