React: Optimization only for env === production

[ghost]

In our development process, we do have a staging env, where we rely on the NODE_ENV being on staging. Since staging should be as close as possible to production, we would like to have the React optimization enabled. Is there a way to explicitly ask for the optimization, without setting the NODE_ENV to production?

[satya164]

One thing I could think of is leave NODE_ENV as production and use another environment variable if you want to detect staging environment somehow.

[ghost]

sure, but this might add confusion about what the "true" env var is.

[aweary]

Currently, there is no explicit way to request that React build for production outside of building with NODE_ENV=production. I'd second what @satya164 recommended, since staging should mirror production as closely as possible. We're looking into implementing a profile build as well (https://github.com/facebook/react/issues/6627) that might be appropriate for staging environments, as it doesn't have the overhead of __DEV__ but also has ReactPerf for profiling.

[davezuko]

@Moezalez For what it's worth, we ran into the same issue and, exactly as @satya164 mentioned, included a DEPLOY_ENV environment variable that we use to determine what the "real" environment is (i.e. for API targets and the like). The reliance on NODE_ENV === production is, unfortunately, not uncommon in the React ecosystem, so, at least for now, we determined this to be the least painful solution to mirroring staging and production environments.

I know this doesn't exactly solve the issue at hand, but I wanted to add a 👍 for this idea as a not-incredibly-awful workaround.

[sebastiandelaroche]

Tengo una idea algo loca y es porque no desarrollar un CLI propio de react, en el que se controle toda la lógica necesaria para empaquetar las aplicaciones desarrolladas en react js.

[ide]

Another explicit +1 to @satya164's recommendation. Since the purpose of staging is to simulate production closely, you should set NODE_ENV=production so that React and all other JS libraries that check NODE_ENV will run as if they were in production.

At Exponent we set another env variable NODE_STAGING=1 so that we can distinguish between staging and production when necessary (ex: our CDN config so that staging mishaps don't break prod) but generally you want staging to look the same as production.

[ghost]

The problem is, that now every dev must learn that env === production doesnt mean production, but might as well be staging. and that just because env === production, that doesn't necessarily mean we can use production APIs.

This might appear small, but those kind of things add up. It's another, small leap to complexity madness, imho

[satya164]

@MoeSattler Yes, but since your staging environment is supposed to mirror the production environment, why shouldn't you use env === production and how'll it work with any node modules or your own code which checks for environment? (and a different env variable for the few things those are different)

[ide]

@MoeSattler If a dev doesn't know that both production and staging are configured with NODE_ENV === 'production', that means all of their code that checks if NODE_ENV === 'production' will run identically in staging in production. That's a good thing because simulating production is one of the main reasons to have a staging environment. So by default, people who are unaware that NODE_ENV === 'production' will write code that does the right thing.

If NODE_ENV === 'staging' in staging, that means that every dev must learn to write NODE_ENV === 'production' || NODE_ENV === 'staging'. That includes all the devs on your team as well as the authors of the all of the npm packages you use that check NODE_ENV as well.

My point is that setting NODE_ENV === 'production' in staging is fundamentally the right thing to do because the purpose of staging is to closely simulate production. And even if devs are unaware of that fact, it will lead them to write code that behaves the same in staging and production; they will naturally fall into a "pit of success".

[gaearon]

I don’t see us changing this. Too much of the ecosystem already depends on this convention. And churn is dangerous because changing anything about it will likely result in breaking people’s dead code elimination pipelines.

React 16 ships with separate entry points for production CommonJS bundles in react/cjs/react.production.min.js and react-rom/cjs/react-dom.production.min.js. You can alias react and react-dom to these bundles to force a production environment even if NODE_ENV says otherwise.

[ghost]

@gaearon alright, thanks for the update.