[Feature Request] Override ENV values in tests

Open
  • Is something wrong?
#1,141 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
bun, typescript
Domain
testing

Research direction

Start by reading the varlock/env initialization and generated schema type entry points, then inspect existing test utilities and environment coercion, validation, and redaction paths. The issue proposes an override helper but does not identify implementation files or tests, so first trace how ENV is resolved and how test mode is determined. Done means a typed helper can apply validated overrides, restore prior values, enforce the test-only or opt-in restriction, and register sensitive values for redaction.

Written by the indexing model from the issue text.

Description

Description

A supported way to override ENV values in tests. ENV from varlock/env is read-only, so a test that needs one flag flipped for one case has to replace the whole module.

Motivation

Say an app has a boolean flag FEATURE_X_DISABLED. To test both branches with bun test, the test has to replace the module:

import * as actual from "varlock/env";

let featureXDisabled = false;

mock.module("varlock/env", () => ({
  ...actual,
  ENV: new Proxy(actual.ENV, {
    get: (target, key) => (key === "FEATURE_X_DISABLED" ? featureXDisabled : Reflect.get(target, key)),
  }),
}));

This depends on the test runner's module mocking, has to be set up before the code under test is imported, and bypasses coercion and validation for the overridden value.

Proposed Solution

A test helper in varlock/env (or varlock/testing), for example:

import { overrideEnv } from "varlock/env";

const restore = overrideEnv({ FEATURE_X_DISABLED: true });
// ...
restore();
  • Typed against the generated schema types.
  • Values are coerced and validated like loaded ones (so "true" becomes true, and an invalid value fails loudly).
  • Only allowed when the resolved environment is test (or behind an explicit opt-in), so it can't flip config in production.
  • Sensitive overrides are registered for redaction like loaded values.
Alternatives
  • Module mocking as above.
  • Setting process.env before import and re-resolving; slow, and does not work once ENV is initialised.
Additional Information

Found while moving a Bun monorepo's hand-written zod env parsing (which was mutable) to varlock.

Dominant language
TypeScript
Stars
4.9k
Forks
140
Avg merge
2d 3h
Merged PRs (30d)
35

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dmno-dev/varlock

All issues in dmno-dev/varlock

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.