[Feature Request] Infer the test environment from the command varlock run launches

Open
  • Is something wrong?
#1,145 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
bun, node.js, typescript
Domain
backend, cli

Research direction

Start at the varlock run command entry point and trace how it resolves VARLOCK_ENV before launching child processes; the issue does not name a source file or test. Check the existing tests for command parsing and environment precedence, then add coverage for the listed runners and bunx/npx forms. Done means recognized test commands select test only when no explicit environment or @currentEnv value overrides it.

Written by the indexing model from the issue text.

Description

Description

When varlock run launches a test runner, infer the test environment from the command itself, so VARLOCK_ENV is test without passing a flag.

Motivation

The Bun guide now recommends varlock run -- bun test. But varlock run resolves before the runner starts, and it's the runner that sets NODE_ENV=test, so VARLOCK_ENV comes out as development. Repro on 1.21.0:

# @defaultSensitive=false
# ---
ENV_NAME=$VARLOCK_ENV

// x.test.ts
import { test } from "bun:test";
test("env", () => console.log("ENV_NAME =", process.env.ENV_NAME, "NODE_ENV =", process.env.NODE_ENV));

varlock run -- bun test prints ENV_NAME = development NODE_ENV = test.

The builtin variables docs cover this and recommend passing the flag explicitly (VARLOCK_ENV=test varlock run -- vitest), so every test script in every package of a monorepo carries it. Forgetting it on one package runs its tests against development config without any error.

Proposed Solution

In varlock run, when VARLOCK_ENV is not already set, look at the command being run: bun test, vitest, jest, node --test, mocha (and the same through bunx/npx) resolve with VARLOCK_ENV=test. An explicit VARLOCK_ENV or @currentEnv value still wins. It could be an opt-in root decorator if guessing from argv is too implicit.

Alternatives
  • Pass the flag in every test script (what the docs recommend today).
  • A varlock test -- <cmd> shorthand that sets the test environment.
Additional Information

The same timing problem applies to anything that sets its own NODE_ENV after startup, but test runners are by far the common case.

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.