TS config paths are not correctly resolved when using @nx/vite:test executor

[getlarge]

Current Behavior

I have been migrating a project from Nx 17.1 to 17.3.2 to integrate the nx release flow. When running the generated migration, it bumped the vite and vitest dependencies, which triggered some unexpected issues.

In a nutshell, here's what we found with @BioPhoton :

• When using custom vite configuration file path(s), vitest fails to resolve the TS config paths when run through the @nx/vite:test executor.
• When running the tests under the given project's folder with vitest (npx vitest --config=<custom-config-file>), they are running.
• When overriding the CWD in vitest executor implementation, TS config paths are resolved correctly.

With this patch (in node_modules/@nx/vite/src/executors/test/vitest.impl.js), i suspect that we are forcing vitest to resolve the config file by itself, probably ignoring the other resolvedOptions

// ...
+    resolvedOptions.root = '.';
+    resolvedOptions.config = _path.basename(resolvedOptions.configFile);
+    process.chdir(_path.join(process.cwd(), projectRoot));
    const ctx = await startVitest((_resolvedOptions_mode = resolvedOptions['mode']) != null ? _resolvedOptions_mode : 'test', cliFilters, resolvedOptions);
// ...

Expected Behavior

I expect the custom Vitest config file to be supported since there is an option (config) supported by the executor to declare the configuration file path.

GitHub Repo

https:/getlarge/vitest-issue-repro

Steps to Reproduce

1. clone the repository
2. install dependencies (npm i)
3. run failing tests - npx nx run coffee-maker:test
4. check the error -> Error: Failed to load url @repro/helpers (resolved id: @repro/helpers) in XXXXX

Nx Report

>  NX   Report complete - copy this into the issue template

   Node   : 20.11.0
   OS     : darwin-arm64
   npm    : 10.2.4
   
   nx                 : 17.3.2
   @nx/js             : 17.3.2
   @nx/linter         : 17.3.2
   @nx/eslint         : 17.3.2
   @nx/workspace      : 17.3.2
   @nx/devkit         : 17.3.2
   @nx/esbuild        : 17.3.2
   @nx/eslint-plugin  : 17.3.2
   @nrwl/tao          : 17.3.2
   @nx/vite           : 17.3.2
   @nx/web            : 17.3.2
   typescript         : 5.3.3

Failure Logs

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Suites 1 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

 FAIL  src/lib/coffee-maker.spec.ts [ src/lib/coffee-maker.spec.ts ]
Error: Failed to load url @repro/helpers (resolved id: @repro/helpers) in XXXX/vitest-issue-repro/packages/coffee-maker/src/lib/coffee-maker.ts. Does the file exist?
 ❯ loadAndTransform ../../node_modules/vite/dist/node/chunks/dep-jDlpJiMN.js:53601:21

Package Manager Version

10.2.4

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

Might be related:

• @nx/vite:test does not find tests with custom vitest config #19076
• Conflicts with package-based monorepo and tsconfig paths aliases (Parsing issue with NxViteTsPaths) + solutions and fixes #21030

[Coly010]

Thank you for bringing this issue to our attention! I want to assure you that I will take a look as soon as I can. Your patience and understanding in this matter is greatly appreciated.

[huv1k]

@Coly010 is there any rough estimate? I know is too much to ask, but just wondering. We wanted update Nx to fix issue with Vitest generator of missing path and now we hit this problem after update 🙈 We really want to move away from Jest, because it blocks us from using ESM :(

[getlarge]

Hi @huv1k, I don't know exactly what blocks you from using ESM with Jest, but I got this setup running in several ESM-based Nx workspace. One of them is open-source, feel free to have a look and send your questions.

[JacobTheEvans]

Any updates on this issue? We are facing this issue for any nx version past 17

[Coly010]

Sorry for the wait everyone, fix is in PR

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.