feat(config): allow imports from local workspace tsconfig paths (#5370)

[garydex]

Description

Fixes #5370 nrwl/nx#17019 remix-run/remix#9171

Uses existing tsconfck dependency to loads the nearest tsconfig file if it exists, grabs any paths from compilerOptions and then makes sure these are not caught by the externalise-deps plugin when resolving imports in the config file.

This functionality is isolated to loadConfigFromFile so does not need to replicate functionality from tsconfig-paths or similar, nor does it duplicate any existing plugins like vite-tsconfig-paths or @esbuild-plugins/tsconfig-paths.

[bolt-new-by-stackblitz[bot]]

Run & review this pull request in StackBlitz Codeflow.

[garydex]

I'm not entirely sure why the windows-latest build is failing; doesn't seem to be related to my changes.

Edit to add: It's running out of memory in the unit tests. I've run the tests on a Windows 10 machine and Node 20, and all tests pass.

[garydex]

That's better - all tests passing now 🥳

It's worth pointing out that I have created an Nx workspace with my patched version of Vite, to demonstrate how a shared config file can be imported and extended - https://github.com/garydex/nx-vite-tsconfig-paths

[bluwy]

Vite doesn't respect the tsconfig paths today, hence I don't think we should fix the problem this way. Similarly in https://github.com/vitejs/vite/issues/6828 where we had discussed and decided that we don't want to have builtin support for it. Tsconfig paths describes the (Vite) runtime and doesn't define it. Sorry for not reviewing this earlier before.

[garydex]

I appreciate the response. A few points:

Vite doesn't respect the tsconfig paths today, hence I don't think we should fix the problem this way. Similarly in #6828 where we had discussed and decided that we don't want to have builtin support for it.

The issue you mentioned is about resolving tsconfig paths across the entirety of Vite. This isn't trying to do that, or replicate/replace vite-tsconfig-paths or similar plugins. It's specific to config, and only executes if there's a tsconfig file that has paths in the codebase.

The other advantage of using the tsconfig paths in this context is that it returns earlier in the build.onResolve - before making any of the resolveByViteResolver calls unnecessarily.

I actually think we may need both this and #17323 - while that PR may fix imports with npm/yarn workspaces, it still doesn't work in a repo that uses tsconfig paths, such as an Nx workspace.

[bluwy]

The issue you mentioned is about resolving tsconfig paths across the entirety of Vite. This isn't trying to do that, or replicate/replace vite-tsconfig-paths or similar plugins. It's specific to config, and only executes if there's a tsconfig file that has paths in the codebase.

The config loading is part of the "experience" of using Vite, so that issue is relevant here too. We can't have tsconfig paths sometimes work here but not there when they work in a Vite project.

[garydex]

Fair point, though I do think it's an equally jarring experience for users who can easily get tsconfig paths to work everywhere in their code except the config file. I understand it's via plugins and out of the scope of Vite itself - but ideally one would be able to at least opt-in for something like this.

[bluwy]

Related https://github.com/vitejs/vite/issues/16718

Closing this as it's not something we want to support in the config.