Parcel: Parcel build picks local .env even when NODE_ENV=produc

[null-saad]

3272 🐛 bug report

I am using parcel to build with vue.js for production as well as local development.

🎛 Configuration

Directory Structure
Project
-pages
--component1.vue
--component2.vue
-App.vue
-main.js
-routes.js
-index.html
-.env
-.env.local
-.env.production

🤔 Expected Behavior

Parcel should build to dist folder with API_ENDPOINT= "/backend_api" as NODE_ENV was set to production

😯 Current Behavior

Parcel builds with local settings i.e. API_ENDPOINT= "http://localhost:5000"

This is so frustrating because if I try the same steps multiple times it works.

💁 Possible Solution

Somehow I can set or force parcel to use a specific .env file

🔦 Context

I want to automate the build to production and with this behavior I have by mistake pushed the local version to production sometimes.

💻 Code Sample

Contents of .env files
.env : empty
.env.local : API_ENDPOINT = "http://localhost:5000"
.env.production : API_ENDPOINT = "/backend_api"

Content of main.js
Vue.prototype.$api = process.env.API_ENDPOINT

Steps to reproduce the issue

1. cd Project
2. set NODE_ENV=production
3. parcel build index.html

🌍 Your Environment

| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 1.10.2
|Vue.js | 2.5.17
| Node |10.15.1
| npm | 6.10.1
| Operating System | Windows 10 64 Bit

[mischnic]

Strange, this is the relevant code: https://github.com/parcel-bundler/parcel/blob/e3c9304/packages/core/parcel-bundler/src/utils/env.js

Could you provide a complete reproduction?

[null-saad]

Hi @mischnic sorry for late reply, I am not sure what exactly are you looking for.
Steps to reproduce the issue

1. cd Project
2. set NODE_ENV=production
3. parcel build index.html

If you are asking other info let me know

[benmai]

I'm running into two problems related to this.

1. I also experience configuration from .env.local going into my production build.
2. I experience this _inconsistently_. Specifically, sometimes production builds contain configuration from .env.local, and sometimes they contain information from .env.production.

@mischnic I read the code you linked and it seems problematic. This line appears to always include .env.local even if it's a production build:
https://github.com/parcel-bundler/parcel/blob/75310e15f6fa3c8a0ce6593ada1bcca00240ea54/packages/core/parcel-bundler/src/utils/env.js#L10-L13

Also, this code has a race condition since it has side effects in a map statement:
https://github.com/parcel-bundler/parcel/blob/75310e15f6fa3c8a0ce6593ada1bcca00240ea54/packages/core/parcel-bundler/src/utils/env.js#L17-L25

What this means is that it will process dotenv files in whatever order they are opened, which explains why my builds _sometimes_ show configuration from .env.local and _sometimes_ show configuration from .env.production.

Am I missing something here? Based on the comment on the first piece of code I linked, we'd want to _remove_ .env.local from the list of dotenv files _if_ the env is test, but not explicitly add it in if we're not in test mode. To make matters more confusing, the official documentation makes no mention of including .env.local when it's not the current environment.

[bichotll]

I can also confirm I'm having the same issue. I couldn't understand what it was going on.
I could help with the PR.

Meanwhile, in case someone is interested in a workaround, I will delete the not wanted env file.

[imjared]

@benmai thanks for your comment and detailed investigation. We have been reaching our wits end both trying to repro this issue and have been going crazy when our steps to repro didn't actually reproduce the issue at hand.

I can't stress enough how scary this bug is since it has the effect of silently and inconsistently changing things like API keys, database URLs, and anything else that would be in a .env file.

In our case, we're relying on .env and .env.production. In dev and sandbox builds, we expect that .env is used. When NODE_ENV is set to production, as it is in our build step, we expect that .env.production is used. As @benmai mentioned in his second note, we have been seeing the expected behavior the majority of the time but it's very hard to tell if/when things fail unless we manually check the source of the output bundle.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.