Run Jest in production mode

[gaearon]

Supersedes #10273.

See individual commits as there’s quite a bit here.

This is almost ready. The rest are actual small differences (e.g. less detailed messages) that I’ll need to fix in the tests themselves. After those are fixed, I’ll add yarn test-prod to the CI runs.

Test Suites: 17 failed, 104 passed, 121 total
Tests:       41 failed, 26 skipped, 2489 passed, 2556 total

[bvaughn]

I see a couple of failures from yarn test-prod that I wouldn't expect to be related to this change, eg: "should throw with non-object in the initial state property" (from the various class-equivalency tests)

    Expected value to be (using ===):
      "span"
    Received:
      "SPAN"

That's a bit odd though b'c you didn't even change this line with the diff.

Edit FWIW, it looks like the checkClassInstance method that throws this error is only run in dev, so these tests should probably be DEV-only. Maybe we should change them too? eg

diff --git a/packages/react/src/__tests__/ReactES6Class-test.js b/packages/react/src/__tests__/ReactES6Class-test.js
index 0df8eaa9e..4f4a93e4e 100644
--- a/packages/react/src/__tests__/ReactES6Class-test.js
+++ b/packages/react/src/__tests__/ReactES6Class-test.js
@@ -163,7 +163,7 @@ describe('ReactES6Class', () => {
     expect(renderCount).toBe(1);
   });
 
-  it('should throw with non-object in the initial state property', () => {
+  it('should throw (in dev) with non-object in the initial state property', () => {
     [['an array'], 'a string', 1234].forEach(function(state) {
       class Foo extends React.Component {
         constructor() {
@@ -174,9 +174,13 @@ describe('ReactES6Class', () => {
           return <span />;
         }
       }
-      expect(() => test(<Foo />, 'span', '')).toThrowError(
-        'Foo.state: must be set to an object or null',
-      );
+      if (__DEV__) {
+        expect(() => test(<Foo />, 'SPAN', '')).toThrowError(
+          'Foo.state: must be set to an object or null',
+        );
+      } else {
+        () => test(<Foo />, 'SPAN', '');
+      }
     });
   }); 

[bvaughn]

There's almost no differences between scripts/jest/dev and scripts/jest/prod except for process.env.NODE_ENV in processor.js and some lines in test-framework-setup.js.

I wonder if you considered using a shared folder for config.js, environment.js, preprocessor.js, setup.js to make maintenance easier later?

I know our team generally seems to be in favor of forking things but that still sits weirdly with me.

[bvaughn]

I think CI might be failing because you added require('shared/ReactFeatureFlags').enableUserTimingAPI to ReactIncrementalPerf-test.js and packages/shared/ReactFeatureFlags.js uses ES module imports?

[bvaughn]

In general, this looks great.

I'm on the fence about some of the duplication. (Left comments.) But I wouldn't block the PR for it. Also left a note about why I think CI is failing, at a glance.

Happy to help clean things up further- particularly the component stack assertions- after this PR is merged if you'd like a hand.

Going to give it the 👍 now even though CI is failing because I trust you.

[gaearon]

I wonder if you considered using a shared folder for config.js, environment.js, preprocessor.js, setup.js to make maintenance easier later?

That was the plan per our earlier conversation in the chat—to unify shared parts after we know everything works (it doesn't yet). Thanks for reviewing!

[gaearon]

To clarify, the outstanding TODOs as I see them in the scope of this PR:

• Fix CI
• Fix remaining tests in PROD mode
• Remove duplication between configurations

[gaearon]

I think CI might be failing because you added require('shared/ReactFeatureFlags').enableUserTimingAPI to ReactIncrementalPerf-test.js and packages/shared/ReactFeatureFlags.js uses ES module imports?

Can you expand on this? We override feature flags this way in a few other tests and it seems to work. npm test also passes locally.

[bvaughn]

To clarify, the outstanding TODOs as I see them in the scope of this PR...

Those TODOs look good.

Can you expand on this? We override feature flags this way in a few other tests and it seems to work.

Shoot. You're right. I was mistaken about that. ☹️ Sorry!

[gaearon]

Filed #11626 and #11618 as followups.