Allow React component displayName and propTypes to be removed in production builds

[re-thc]

Hi, can proptypes be removed from the production builds? Saves ~3kb. It's good for development but would be better if it's not exported out. Thanks.

Can be done via a babel plugin.

[jaydenseric]

Yes, it is a good idea to avoid prop-types in production bundles, but the actual elimination of it should happen when a user builds their project; we don't publish separate development and production versions of graphql-react. We should however make sure what we publish works well with tooling such as Webpack via Next.js.

I had just assumed that Next.js eliminates prop-types in production builds for both project code and dependencies, but I do wonder if maybe that's not true - it would be good to test it out.

To be sure, we should conditionally define propTypes on components via a process.env.NODE_ENV !== 'production' condition, like how other packages such as react-redux does it:

https://github.com/reduxjs/react-redux/blob/f0124d71f959224fd1aebc02d50ce0069e58c5e5/src/components/Provider.js#L36-L37

I'm not a fan of using process.env.NODE_ENV because that won't work without a bundler; process is undefined in a browser. Maybe there should be a more complicated typeof process !== 'undefined' && process.env.NODE_ENV check.

[jaydenseric]

So, this would be a breaking change for anyone that doesn't have a bunder that deals with process being undefined in browsers (or any non-Node.js environment really):

Although it's a little more verbose, this is not a breaking change:

Here they are compared in a Next.js production build:

The propTypes are successfully eliminated for both, although the second option causes slightly more complicated code for some reason beyond my understanding.

[jaydenseric]

This improvement has been published in v11.1.0 🚀