There's no standardized, cross-platform, developer-friendly way to detect what environment you're running code in. The JS community has generally centered around reading process.env.NODE_ENV, but this property feels out of place in browser code, and requires a lot of typing at every usage (it's too easy to get wrong or flip the condition backwards). Some people set up __DEV__ to transpile down to process.env.NODE_ENV !== 'production' for a better developer experience.
A new property, hung on the global object. This spec is to satisfy node, browser, and native.
This is still in discussion, but seems to fall into two camps:
In this proposal, global.env is a string that resolves to the NODE_ENV.
if (global.env === 'production') {
// use fast path...
}In this proposal, global.env is an object with helpers to quickly determine the environment the code is running in.
if (global.env.production) {
// use fast path...
}Using global means that it'll work where ever process.env is being used today, and global is on the standards track, and will likely hit browsers as well. Hanging a property on global ensures that the developer experience is solid, without.
There's no current env property on global in Node, WebPack, or Browsers. Therefore, the property should be web-safe. It also aligns with prior process.env.NODE_ENV usage cleanly, and provides clear signal of what it does to developers.