[BUG]: Bun auto-loading .env files conflicting with varlock loaded env

[trevordcampbell]

varlock version

0.0.11

Steps to reproduce

1. Clone repo: https://github.com/trevordcampbell/varlock-testing

2. Open project in DevContainer (Already fully configured)

3. Install: bun install

4. Run the script with all possible environments:

# Test 1: Load command with production env
APP_ENV=production bun varlock load
# Expected:
# ✅ APP_ENV*: "production"
# ✅ LOG_LEVEL*: "warn"
# ✅ OVERRIDE_LOADED_FROM*: "production"
# Actual output:
# ✅ APP_ENV*: "production"
# ✅ LOG_LEVEL: "debug"
# ✅ OVERRIDE_LOADED_FROM*: "development"

# Test 2: Run command with production env
APP_ENV=production bunx varlock run -- bun script.ts
# Expected output:
# APP_ENV: production
# LOG_LEVEL: warn
# OVERRIDE_LOADED_FROM: production
# Actual output:
# APP_ENV: production
# LOG_LEVEL: debug
# OVERRIDE_LOADED_FROM: development

# Test 3: Run command with staging env
APP_ENV=staging bunx varlock run -- bun script.ts
# Expected output:
# APP_ENV: staging
# LOG_LEVEL: info
# OVERRIDE_LOADED_FROM: staging
# Actual output:
# APP_ENV: staging
# LOG_LEVEL: debug
# OVERRIDE_LOADED_FROM: development

What is expected?

When setting APP_ENV=production, Varlock should:

1. Load .env.production override file
2. Apply production-specific environment variables
3. Show OVERRIDE_LOADED_FROM=production

What is actually happening?

Regardless of APP_ENV value, Varlock:

1. Always loads .env.development override file
2. Applies development-specific environment variables
3. Always shows OVERRIDE_LOADED_FROM=development

System Info

System:
    OS: Linux 6.15 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
    CPU: (14) arm64 unknown
    Memory: 12.12 GB / 15.66 GB
    Container: Yes
    Shell: 5.9 - /usr/bin/zsh
  npmPackages:
    @biomejs/biome: ^2.2.2 => 2.2.2 
    @types/bun: latest => 1.2.21 
    turbo: ^2.5.6 => 2.5.6 
    typescript: ^5.9.2 => 5.9.2 
    ultracite: ^5.2.5 => 5.2.5 
    varlock: latest => 0.0.11

Any additional comments?

Notes:

• This is using Bun instead of npm / pnpm
• This is running in a DevContainer (usually not relevant... but sometimes it is!)

[philmillman]

I have a feeling this is bun related. @trevordcampbell is it working as intended with (p)npm?

[trevordcampbell]

I have a feeling this is bun related. @trevordcampbell is it working as intended with (p)npm?

I've switched the testing container over to Node + pnpm, and Varlock loading works as expected:

APP_ENV=development npx varlock run -- node script.ts
# APP_ENV: development
# LOG_LEVEL: debug
# OVERRIDE_LOADED_FROM: development

APP_ENV=production npx varlock run -- node script.ts
# APP_ENV: production
# LOG_LEVEL: warn
# OVERRIDE_LOADED_FROM: production

So it does look indeed look like a Bun issue 😢☠️

[philmillman]

I have a feeling this is bun related. @trevordcampbell is it working as intended with (p)npm?

I've switched the testing container over to Node + pnpm, and Varlock loading works as expected:

APP_ENV=development npx varlock run -- node script.ts

APP_ENV: development

LOG_LEVEL: debug

OVERRIDE_LOADED_FROM: development

APP_ENV=production npx varlock run -- node script.ts

APP_ENV: production

LOG_LEVEL: warn

OVERRIDE_LOADED_FROM: production

So it does look indeed look like a Bun issue 😢☠️

Yeah I think it has to do with how it loads env files itself, https://bun.sh/guides/runtime/set-env

Although it seems to be working for me:

[trevordcampbell]

Interesting, weird that it works for you! My guess for that discrepancy is that you're running it locally and not in the DevContainer (devcontainer is running a linux image, so probably some subtle bun runtime / execution differences there between machines).

But I did switch APP_ENV --> NODE_ENV in the bun implementation, and that works successfully as expected (when run inside the DevContainer):

NODE_ENV=development bunx varlock run -- bun script.ts
# APP_ENV: development
# LOG_LEVEL: debug
# OVERRIDE_LOADED_FROM: development

NODE_ENV=production bunx varlock run -- bun script.ts
# APP_ENV: production
# LOG_LEVEL: warn
# OVERRIDE_LOADED_FROM: production

At least it's a simple fix for now! ✅ Good catch – Thanks for digging into it!