Allow augmentation of env in the InlineConfig interface for type-safe env vars,

[danwithabox]

Clear and concise description of the problem

I want to pass down a config-defined env var via a global setup file to test files with provide(), and have it be type-safe all the way through.
provide() can be made type safe via ProvidedContext, but InlineConfig.env cannot be.

When writing

// vitest.config.ts
export default defineConfig({
    test: {
        env: {
            MY_CUSTOM_ENV: "foo",
        }
    },
}),

and

// globalSetup.ts
import type { GlobalSetupContext } from "vitest/node"

export default function setup({ config, provide, }: GlobalSetupContext) {
    const myCustomEnv = config.env.MY_CUSTOM_ENV;
    provide('myCustomEnv', myCustomEnv);
}

declare module "vitest" {
    export interface ProvidedContext {
        myCustomEnv: "foo" | "bar", // or, I guess, could be InlineConfig["env"]["MY_CUSTOM_ENV"]
    }
}

I would like MY_CUSTOM_ENV to be type-safe and have autocompletion in:

• defineConfig()'s test.env
• globalSetup.ts's config.env

I attempted to augment the InlineConfig interface:

// vitest.d.ts
declare module "vitest" {
    export interface InlineConfig {
        // Error: ts(2717)
        env?: {
            MY_CUSTOM_ENV: "foo" | "bar",
        },
    }
}
export {};

but as expected, this results in:

Subsequent property declarations must have the same type.  Property 'env' must be of type 'Record<string, string> | undefined', but here has type '{ MY_CUSTOM_ENV: "foo" | "bar"; } | undefined'.ts(2717)

Considering I'm used to overriding import.meta.env in Vite, and since declaration-merging ProvidedContext works great as well, I'd like the same capability for InlineConfig.

Suggested solution

Instead of

interface InlineConfig {
    // (...)
    env?: Record<string, string>;
    // (...)
}

env should have its own augmentable interface, similar to how ProvidedContext works, e.g.

interface InlineConfigEnv {
}
interface InlineConfig {
    // (...)
    env?: InlineConfigEnv;
    // (...)
}

Also, it seems .env is not documented at all over at https://vitest.dev/config/, even though it looks like part of the stable public API, has JSDoc and everything.

Alternative

No response

Additional context

No response

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.

[sheremet-va]

I guess we can set it to Partial<NodeJS.ProcessEnv> to allow augmentation

[danwithabox]

Blinded by my need to just abuse this as a way to pass data from config to tests, I didn't even think of NodeJS.ProcessEnv, but that makes prefect sense and would be happy with it 😄