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