GATSBY_ACTIVE_ENV vs. NODE_ENV – confusion

[joefiorini]

Summary

As of #10565 Gatsby supports overriding the default NODE_ENV by specifying a GATSBY_ACTIVE_ENV environment variable. This is exactly the functionality I wanted when I was figuring out how to load my app's .env.{env name} config files into the gatsby build. However, now my build is breaking at runtime (seeing the same error as in #8285) because the webpack define plugin is getting the value of GATSBY_ACTIVE_ENV as process.env.NODE_ENV instead of the NODE_ENV set by calling gatsby build. It seems like whatever is set for GATSBY_ACTIVE_ENV should not replace the NODE_ENV value originally set by gatsby, right?

Steps to Reproduce

Run gatsby serve with GATSBY_ACTIVE_ENV=staging, then try to hit one of your pages, you should see an error in loader.js saying that syncRequires.components is undefined.

Expected Behavior

When running gatsby build or gatsby serve, process.env.NODE_ENV should be production, regardless of the value specified for GATSBY_ACTIVE_ENV. This behavior is what I expected based on my interpretation of the docs which say:

As noted above NODE_ENV is a reserved environment variable in Gatsby as it is needed by the build system to make key optimizations when compiling React and other modules. For this reason it is necessary to make use of a secondary environment variable for additional environment support, and manually make the environment variables available to the client-side code.

It sounds like I should never be able to change NODE_ENV no matter what I pass, yet clearly I can.

Happy to open a PR fixing this issue (and maybe cleaning up the docs a bit to clarify the use of GATSBY_ACTIVE_ENV & autoloading .env). I just want to make sure that the issue I'm noticing is actually a bug and not the intended behavior first.

[joefiorini]

This may be a duplicate of #13273, or at the very least share a root cause.

[wardpeet]

Yeah it's a bug and indeed a duplicate of #13273. I'm closing it in favor of that issue.

I have a PR up that fixes it. I also added a test.

[joefiorini]

@wardpeet Great, thanks so much for the quick turnaround on this! A little disappointed I didn't get to fix it myself, but happy to see it fixed! I'm sure I'll find other opportunities in the future. Looking forward to this getting released.

[wardpeet]

Oh my bad, will keep it open next time.