Disable reading `.env`

[robobun]

Hello everyone! I'm testing out Bun as Node.js drop-in replacement in one of my most important projects.
As per title I usually have a package.json scripts.prepare script in order to install git hooks using husky (https://typicode.github.io/husky/getting-started.html#install).

{
  "scripts": {
    "prepare": "husky install" 
  }
}

So when building my docker image I usually do something like this before installing only production deps:

RUN npm pkg delete scripts.prepare

Instead the deps installation will fail.

Any bun suggestion / alternative to this step? Thanks!

Originally reported on Discord: Bun "npm pkg delete scripts.prepare" alternative

[andreafspeziale]

Actually the title is not reflecting the issue body.
First question was about the presence of a command like npm pkg delete.

After getting the following response:

We don't have anything like that at the moment I'm afraid 
You could keep using the npm command

Or write a small .ts script that reads, modifies, and re-writes that package.json
Though actually you should probably just disable husky with an environment variable: https://typicode.github.io/husky/guide.html#disable-husky-in-ci-docker-prod

which is totally fine. In the same thread I also asked if there was any command option in order to disable .env autoloading. I would find convenient in some use-cases (nestjs/config#1461)

[np-kyokyo]

I am currently facing this issue.

.env

VAR=sample

.env.stg

VAR=sample2

When there are .env files as above, using "scripts": { "build:stg": "vite build --mode stg" } and then bun build:stg, bun will first load .env, and vite does not overwrite the value of a variable that has already been loaded name, so VAR from .env.stg will not be loaded. As a result, VAR will be loaded with value sample, which is contrary to the intention.

revision: Described above is edited version. I apologize for the lack of concreteness in the original text. The original comment was intended like as above. And it seems I was mistaken in how to use .env. After I changed the using of .env to contain only variables common to all environments, I got to be able to use .env without such a problem. Therefore, I am currently not facing that issue. I apologize for the lack of concreteness in the original text.

[SoprachevAK]

I also experienced this problem while using Vite. They have they own .env loader with another logic, but current environment has max priority and override their build based logic. Its not cool

[lsnow99]

I'd also like a way to disable this behavior- it was unexpected and caused some headache debugging. I'd be happy to PR an environment variable or other config option to allow disabling if that would be acceptable

[graphenn]

We are experiencing the same issue as @np-kyokyo. It seems that Bun’s behavior differs from Node.js in this foundational and core feature, which may limit its use as a complete drop-in replacement for Node.js with popular vite projects. Additionally, here is a same issue #13614

[graphenn]

Maybe we can disable reading the .env file by using bun --env-file "".

.env

VITE_APP_ENV=env_base

.env.prod

VITE_APP_ENV=env_prod

bun --print process.env | grep VITE
  VITE_APP_ENV: "env_base",

bun --env-file "" --print process.env | grep VITE
(no result)

This shows that no environment file variables are loaded.

But this does not work for bunx, as noted in this issue #12430.

npx vite build --mode prod

...
env_prod VITE_APP_ENV


bun --env-file "" --bun vite build --mode prod

...
env_base VITE_APP_ENV

The result shows that when use bun, the .env file is loaded, but .env.prod is not.
node works well.

[rynvelt]

I also experience this and it is quite annoying because Vite has the convention of loading environment variables from specific files with some precedence, see https://vite.dev/guide/env-and-mode.html#env-files - one of those files that can be used for shared environment variables is named .env

[pesterhazy]

Is it really true that it's not possible to disable reading .env? This is inconvenient, as it can break tests etc

The fact that bun reads .env without being asked to can also cause security issues, if e.g. .env contains secrets