Parcel build setting NODE_ENV=production always

[lbguilherme]

🐛 bug report

I use parcel to build my node apis, this includes both the production and staging environment. For production I do:

# ...
ENV NODE_ENV production
# ...
RUN npx parcel build src/main.ts -d out --no-minify --target=node
# ...

And for staging my Dockerfile is:

# ...
ENV NODE_ENV development
# ...
RUN npx parcel build src/main.ts -d out --no-minify --target=node
# ...

Which is well within best practices. The NODE_ENV variable is later used in the code to decide in which database to connect.

Today I upgraded to parcel 1.8.1, and deployed to the staging environment for testing. This same branch also does some heavy migrations on the database, changing schema of some core tables, and dropping a few others. This code wasn't ready for production.

But then comes this change on 1.8.1:

parcel/src/cli.js

Lines 172 to 176 in dc10531

	if (command.name() === 'build') {
	process.env.NODE_ENV = 'production';
	} else {
	process.env.NODE_ENV = process.env.NODE_ENV || 'development';
	}

WTF? Seriously? I can't parcel build for staging?

Fast forwarding: The staging environment connected to the production database and ran all that bad test migrations which destroyed data.

Let's revert it, shall we?

[lbguilherme]

This was already fixed by #1323 but wasn't released yet. Previously env were not replaced for node, now in 1.8.1 it is replaced with "NODE_ENV=production" for node too.

I'm closing this. But please release 1.8.2 with this fix.

[devongovett]

I don't think this is parcel's fault. That was not a change in 1.8.1, that code has been there since parcel 1.0.0. And it does not set the environment variable external to the node process, so I'm not sure how it would affect anything outside of parcel.

[lbguilherme]

The faulty commit is actually #1166. It moves env replacement to pretransform and removes the check if target=browser, that was there before. As consequence of both this and replacing NODE_ENV, it is rewritten to "production". This was released on 1.8.1 (or 1.8.0?).

The fix is already merged on master: #1323, but wasn't released yet.

[micksatana]

In 1.9.2, this problem still persists. When put in script NODE_ENV=staging parcel build the environment is set to production.

[lbguilherme]

Are you building for Node or for the Browser? On 21 Jun 2018 03:35, Satana Charuwichitratana <[email protected]> wrote:In 1.9.2, this problem still persists. When put in script NODE_ENV=staging parcel build the environment is set to production. —You are receiving this because you modified the open/close state.Reply to this email directly, view it on GitHub, or mute the thread.

[micksatana]

yes, i'm building for browser. I use NODE_ENV to determine which configurations to be used.

[lbguilherme]

For the Browser, parcel always set NODE_ENV to production. This is not a bug, this is a "wontfix" / feature.I'm not sure if I disagree with the decision, it does make usage easier. But at the same time, it is unexpected. A perhaps it should be set to production only if it is not set already? On 21 Jun 2018 04:00, Satana Charuwichitratana <[email protected]> wrote:yes, i'm building for browser. —You are receiving this because you modified the open/close state.Reply to this email directly, view it on GitHub, or mute the thread.

[micksatana]

IMHO, If it's not already set, then set to production is good. But when it is set to environment like staging and unexpectedly changed to production, this could destroy the production. For example, when using Parcel with CI/CD to build staging environment for testing, all staging test data might unexpectedly go to production. This is not happen to me though, but I've seen some incidents like this.

Just in case someone else having similar issue, I recently use NODE_ENV=staging parcel serve to build instead, the environment not being overwritten if you use serve command.

[micksatana]

Just want to give some example of how this could affect production even when the NODE_ENV only set during parcel run build. The problem could happen when some web app rely on NODE_ENV during build-time to change target database or api endpoint that the web app will be working on.

For example, a web app using .env to configure its database and api endpoint during build-time. The app is built using Parcel along with CI/CD to automate testing on staging environment, says resetting database, test API, etc. After built, the environment unexpectedly changed to production and the automated tests run, as a result the production data will be gone.

Anyway, I still prefer parcel over other tools and continue using it. Just hope this explanation helps to reconsider decision on the "wontfix" feature.

[tomasdev]

I'm on the same boat than @micksatana ... configuring parcel build entry.html on the CI scripts for stage/qa/uat et al, because we don't need to run a server but at the same time having to deal with "production" being set... ended up passing extra environment variables to distinguish each deployment.

[micksatana]

FYI, I just noticed. According to these lines, the issue is fixed in v1.9.3

parcel/src/cli.js

Lines 179 to 183 in 2aa7215

	if (command.name() === 'build') {
	process.env.NODE_ENV = process.env.NODE_ENV || 'production';
	} else {
	process.env.NODE_ENV = process.env.NODE_ENV || 'development';
	}

So in case anyone still in 1.9.2, just upgrade and you don't need this workaround.

IMHO, If it's not already set, then set to production is good. But when it is set to environment like staging and unexpectedly changed to production, this could destroy the production. For example, when using Parcel with CI/CD to build staging environment for testing, all staging test data might unexpectedly go to production. This is not happen to me though, but I've seen some incidents like this.

Just in case someone else having similar issue, I recently use NODE_ENV=staging parcel serve to build instead, the environment not being overwritten if you use serve command.