[BUG]: Auto-load re-resolve inside varlock run fails when an @internal value came from the shell

Open
  • Is something wrong?
#1,138 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
43/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
bun, typescript
Domain
backend, security

Research direction

Start by tracing how varlock run strips @internal values and how JavaScript auto-load re-resolves after an env file change; the issue names the auto-load integration and the varlock run -- bun check.ts reproduction, but no source files or tests. Reproduce both steps and inspect the injected env blob and child process handling. Done when the second command still resolves SERVICE_URL from the shell-provided SUBDOMAIN.

Written by the indexing model from the issue text.

Description

varlock version

1.21.0

Steps to reproduce

.env.schema:

# @defaultSensitive=false
# ---
# Comes from the shell, only used to build SERVICE_URL.
# @internal
SUBDOMAIN=
SERVICE_URL=https://${SUBDOMAIN}.example.com

check.ts:

await import("varlock/auto-load");
console.log("SERVICE_URL =", process.env.SERVICE_URL);
  1. SUBDOMAIN=api varlock run -- bun check.ts
  2. SUBDOMAIN=api varlock run -- sh -c 'echo "# edited" >> .env.schema; bun check.ts'
What is expected?

Both print SERVICE_URL = https://api.example.com. The second is the watch-mode case the JavaScript guide describes: an env file changes while the app runs under varlock run (for example varlock run -- bun run --watch src/index.ts), and auto-load re-resolves instead of reusing the blob.

What is actually happening?

1 works. 2 fails:

❓ SUBDOMAIN*  🔩internal
   └ undefined
   - Value is required but is currently empty
⛔ SERVICE_URL*  🔐sensitive
   └ undefined
   - Dependency SUBDOMAIN is invalid

varlock run strips @internal items from the child env, including values that came from the ambient environment (as documented). When the child's auto-load then re-resolves because an env file changed, the internal value is no longer there to resolve from, so the load fails. The same happens to a secret-zero passed in from the shell, for example an OP_TOKEN of type opServiceAccountToken: editing an env file during a watch session breaks every op() item. Without @internal, step 2 works.

Possible fixes: carry internal ambient values in the (encrypted) blob for re-resolution only, or have auto-load re-resolve through the parent varlock run, or document that re-resolution in a child cannot see internal items.

System Info
macOS 27.0 (arm64)
Bun 1.4.2
varlock 1.21.0
Any additional comments?

Hit in a Bun monorepo where a value set by the shell per checkout feeds other items; we had to drop @internal from it so a watch session survives an env edit.

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.