Eagerly evaluate inline requires in Jest

[gaearon]

I inlined some requires in #7188 to fix the build size regression.
However this caused an issue with Jest due to it resetting module registry between tests.

This is a temporary fix to #7240.
It should be reverted as part of #7178.

Test plan:

1. Verify "Missing React element for debugID" warning when testing components with Jest #7240 is fixed by following its repro instructions. You would need to build React and copy build/modules/* into its node_modules/react/lib/.
2. Verify a React example (e.g. basic-click-counter) in the repo runs with minified and unminified React.
3. Check that the minified build size has not increased.

Reviewers: @zpao @keyanzhang

(Yes I know it’s super ugly. The upside is I know Jest a little better now!)

[gaearon]

@cpojer Does this look reasonable to you as a stopgap solution? (We have a better solution in #7178.)

[gaearon]

@keyanzhang Do you think we’ll get #7178 in this week? If yes, maybe we don’t need to bother with this fix.

[keyz]

@gaearon I'll get that PR ready in a few days. Just to clarify -- we run these tests with the development build right?

[cpojer]

Yeah this seems reasonable. I'm sorry for the pain.

I'm however unsure how rollup would solve this as people will use the dev code (react/lib/*), not the production build when writing unit tests.

[gaearon]

Yes, we run tests with development CommonJS build. Rollup would solve this because we can move requires back to the top of the file (like Jest prefers) but it would still eliminate dead code in prod. Browserify is not that smart which is why I inlined them, but I won't have to after switching to Rollup.

[cpojer]

oh, yeah, that makes sense!

[zpao]

I fully expect this to break internally unless we check if (process && process.env && process.env.NODE_ENV = 'test').

[gaearon]

Aah, __DEV__ “works” because it’s how it’s called internally! :steve_jobs_fireworks:

[gaearon]

Okay, this should work, right? This is getting super hacky. 😢

[gaearon]

1. This should work in FB because typeof process should give undefined as it’s an unknown global.
2. This should work in CommonJS because process should give whatever your bundler gives you, and we don’t care whether it exists or not thanks to the same check.
3. This should work in our UMD builds because we don’t use process anywhere except those "test" checks so it’s safe to force Browserify to use undefined there. Our __DEV__ clauses still work because they get envified.
4. This works in Jest because, well, process exists there.

[gaearon]

@zpao Shall we do it?

[zpao]

Sure, but let's make sure this doesn't stick around for long.