Introduce __PROFILE__ build

[gaearon]

As discussed in #6015, we plan to add a new build configuration that does not have the __DEV__ overhead but that comes with the new ReactPerf enabled.

This means that developer warnings, etc, will need to be gated by __DEV__, but the component tree (#6549) and some other events (e.g. #6612) will need to be gated by __PROFILE__.

I’m curious how this could be implemented. Right now our system is simple:

Current System

Variables

• __DEV__ = (process.env.NODE_ENV !== 'production')

Development Build (any NODE_ENV except 'production')

• __DEV__ is true

Production Build (NODE_ENV is 'production')

• __DEV__ is false

As you can see, if process.env.NODE_ENV is omitted, we assume __DEV__ mode. This is a sensible assumption, and not the one we want to change, as most projects today don’t specify anything as NODE_ENV in development, and we don’t want them to suddenly lose all developer warnings.

Therefore, I propose the following new system:

Proposed System

Variables

• __DEV__ = (process.env.NODE_ENV !== 'profile' && process.env.NODE_ENV !== 'production')
• __PROFILE__ = (process.env.NODE_ENV === 'profile')

Development Build (any NODE_ENV except 'profile' or 'production')

• __DEV__ is true
• __PROFILE__ is true

Profile Build (NODE_ENV is 'profile')

• __DEV__ is false
• __PROFILE__ is true

Production Build (NODE_ENV is 'production')

• __DEV__ is false
• __PROFILE__ is false

This would let us have three separate build configurations. We can use the same pattern in other fbjs projects as well, if desired. I would say it’s unlikely we’d ever want to add a separate fourth configuration so this should cover all our needs.

Any thoughts why this would be a bad idea? Should I implement this in fbjs?

cc @facebook/react-core

[gaearon]

If we go with this system, we’ll also probably want to run some tests (like ReactPerf tests) with __DEV__ set to false but __PROFILE__ set to true, to emulate the profile build.

[sebmarkbage]

Makes sense to me. The only issue here is what we do about internal Facebook code and React Native because this system doesn't exist there. We would probably need to make this push universal and talk to stakeholders instead of just going our own way. At the very least we'll need a way to deploy this to www where we don't use the pre-compiled version. cc @zpao

[ForbesLindesay]

I think for profiling you want libraries like redux in prod mode by default. I would therefore stick to only two values for NODE_ENV and instead add a new PROFILING variable (which would default to NODE_ENV != production