v0.5.2 does not allow running local applications from tests

ffMathy commented 6 months ago

Describe the bug

My local tests are integration tests, that run towards a sandbox AWS environment. For this, they use the AWS Node Credential Provider, which (by default) tries to read your AWS config and retrieve credentials from there.

But my config points to a credential_process, which automatically makes AWS sign in with company-SSO login to AWS, and get a temporary token as needed, when it expires.

More information:

Before v0.5.0, this worked fine. The credential process could spin up (it is invoking the Azure CLI az). But now, it says it is no longer found.

Reproduction

Install the Azure CLI (az) on your machine or any other CLI application. Doesn't matter. It just has to be reachable globally.

Make a jest.global-setup.ts file that spins up that CLI application. In this example, we are using az --version.

import execa from 'execa';

export default async function () {
  const result = execa.sync('az', ['--version']);
  console.log(result.stdout);
}

Set up your vitest.workspace.ts to point to your global setup file:

import { UserConfig, defineWorkspace } from "vitest/config";

const userConfig: UserConfig = {
  test: {
    globals: true,
    globalSetup: ['./jest.global-setup.ts'], //this is the important line
    environment: 'node',
    include: ['**/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}'],
  }
};

export default defineWorkspace([
  userConfig
]);

Try to expand a test to discover or run it. You will see this in the Vitest output window:

[Error 9:57:37 PM] [Worker] ⎯ Error during global setup ⎯⎯

[Error 9:57:37 PM] [Worker] Error: Command failed with ENOENT: az --version spawnSync az ENOENT

[Error 9:57:37 PM] [Worker] ❯ Object.spawnSync node:child_process:890:24 ❯ module.exports.sync node_modules/.pnpm/execa@5.1.1/node_modules/execa/index.js:174:25 ❯ vite_ssr_exports.default [as setup] jest.global-setup.ts:8:48

[Error 9:57:37 PM] [Worker] ❯ s ../../root/.vscode-server/extensions/vitest.explorer-0.5.3/dist/worker.js:3:1740

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

[Error 9:57:37 PM] [Worker] Serialized Error: { errno: -2, code: 'ENOENT', syscall: 'spawnSync az', path: 'az', spawnargs: [ '--version' ], originalMessage: 'spawnSync az ENOENT', shortMessage: 'Command failed with ENOENT: az --version\nspawnSync az ENOENT', command: 'az --version', escapedCommand: 'az --version', exitCode: undefined, signal: undefined, signalDescription: undefined, stdout: '', stderr: '', failed: true, timedOut: false, isCanceled: false, killed: false }

System Info

System:
    OS: Linux 6.6 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
    CPU: (10) arm64 unknown
    Memory: 11.90 GB / 15.60 GB
    Container: Yes
    Shell: 5.2.15 - /bin/bash
  Binaries:
    Node: 20.11.1 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.4 - /usr/local/bin/npm
    pnpm: 8.15.4 - /usr/local/bin/pnpm
  IDEs:
    VSCode: 1.87.2 - /vscode/vscode-server/bin/linux-arm64/863d2581ecda6849923a2118d93a088b0745d9d6/bin/remote-cli/code
    Vim: 9.0 - /usr/bin/vim
  npmPackages:
    @vitejs/plugin-react: ^4.2.1 => 4.2.1 
    @vitest/coverage-v8: ^1.3.1 => 1.3.1 
    @vitest/ui: ^1.3.1 => 1.3.1 
    vite: ^5.1.6 => 5.1.6 
    vitest: ^1.4.0 => 1.4.0

Used Package Manager

pnpm

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.

ffMathy commented 6 months ago

Is this perhaps a limitation of workers in general?

sheremet-va commented 6 months ago

In your case the problem is probably because the working directory is different.

We should probably start a new process for every config file, so the working directory is always correct. I also wonder if we can show the notification if too many configs are found snd recommend using the workspace feature instead.

ffMathy commented 6 months ago

But az is a globally installed application. It's accessible from anywhere, no matter what directory you're in. It was working before no matter what working directory it was running from.

ffMathy commented 6 months ago

This has now been resolved. Thanks.

vitest-dev / vscode