add process guard

[guybedford]

This fixes react-transition-group to work with "module" resolution on JSPM. See the example at https://jspm.org/sandbox#H4sIAAAAAAAAA61W32/aMBB+719xy172o0lKta6MQUXHqqobdFVp1e3RJAfxFtuRz0DptP99FwcYoJZW2x4gsn333Xd38XdpPktN4mYFQuZUfrTTXDxQpEc7AE2FTkCSCUvoWsHYDcN64A+cdDkeXWv/TJtxtV66aKGwFUwkTgtjXQCJ0Q41Q0xl6rJWihOZYOgXuyC1dFLkISUix1aNAzTjikFzYNKZR30WhvwA+NS/6MEparTCGQtnqsSHnij86UkqHVxfdhucjyuoEcejhWn0nQoVSRM/v94/z76dfvjxsbdnZ/27T/3rWvb5pDi/6hxedvv557vO5Eu3p3t3787Pu3Uz6X49nu5dXVz2pmfHQ9W5cX065mhh6IlRYmXhoCxiK5CejhKFL9JPz2m+SUFjvsFbFkXiQmeFJk7d6HBkzbhgi2DJWywJ60I17ndov4neRPsxkoqlTvGWXQIf4tduFZoSU+Ba5HvwV47ZoD0QA8xjO+bWKuQ+5AVa8jEEEVp3lUk6qzom7zDdQnodqn0Y1d5GB48jllnsPokQ3vJLldI/UZhjPD2o1Bla6ahrDOE/hV5DejoBM/iOibuRLjNjd2G5w9ZJ/A98tgFv0EuNCheuIk07OXdyS+wV8/ZBtB/tVd2fO27BtqjMBP8OfsV3I0KVaMgHcqS34K7Z8WWrRbU/F20Fr+BahaUCbCP5x6hdO4jqTPI+KH/RHxOCdu0w2uOL/yBAyBV5VE3YZhsQJRmm4xztFqClTZtR1oDmOL92Fv/lrxlXalmK41zU4aQPPVNiQD+TihoLSWcRJShMPhvKPIcha73yZgQDa6YsGwTT6k0FueJB48IvXgj2wtsEWZs7mTUKof7u9csN1RY00wmQTVoPZYgUVnFDKulxnrX9qB6nkly8cRYpqcvUIbGGyFg5kroVCG30TJkxBUeb6a+NjgrJzw1YZPSKCYJv1tVS+U9L4YchZ/TgGHlf4QPEMdywwCCXRup5/XgUpzzu0eIucFE5gADCQvCQROBaoy8rbwZclgCEc1YOxnxmNLgMFygV98iH4eFOJscoN6MX97F9+X6t9824muo85P3Xxm9INbHXhQgAAA== for the issue.

[koba04]

@guybedford
Thank you for your work!
I think process.env.NODE_ENV is intended to be replaced with the actual value of NODE_ENV in build time. If we add a guard condition like this PR, this would become a problem because typeof process !== 'undefined' is always false in runtime.

// When NODE_ENV is "development"
typeof process !== 'undefined' && process.env.NODE_ENV !== 'production'
// This becomes like the following in runtime
typeof process !== 'undefined' && "development" !== 'production'
// process is undefined in runtime, so this condition is always `false`

But, I understand your concern, so we should find a way to work with JSPM.

[guybedford]

@koba04 process is a Node.js global variable - not a browser one. So the pattern of assuming it exists in browser modules means the browser modules being written are not real browser modules (https://twitter.com/guybedford/status/1474434054590107649?s=20).

Build tools that handle the replacement should know to intelligently replace the typeof check as well. I haven't tested recently, but I believe Webpack does this and it's maybe just RollupJS that doesn't?

Perhaps we can follow up with build tool issues further as this is important to fix.

[koba04]

Personally, I'd like to remove prop-types from its dependencies because it's no longer a popular way of checking props. But our API documentation in the website depends on propTypes, so we have to remove the dependency before removing it.

I noticed that prop-types is used in other places without the guard condition, such as https://github.com/reactjs/react-transition-group/blob/master/src/Transition.js, so I'm curious why the guard condition is only required here. Could we remove the condition? It would be nice if we could remove the condition without adding the guard condition.

[guybedford]

Checking src/Transition.js it looks like that does import the src/utils/PropTypes.js file, so does effectively depend on the guard as well.

Agreed fully removing would be nice, was just posting the easiest fix to start.

I will aim to follow up build issues if that's a concern.

[koba04]

@guybedford I've noticed that there are other process.env.NODE_ENV in the build files. react-transition-group uses babel-plugin-transform-react-remove-prop-types, which is a babel plugin to remove PropTypes definitions from production builds. It inserts process.env.NODE_ENV !== "production" into assignments of propTypes with the wrap option. https://www.npmjs.com/package/babel-plugin-transform-react-remove-prop-types

If we keep using PropTypes, we have to remove the babel plugin as well.

[koba04]

I'd like to take an option to remove PropTypes to fix this issue.