{"action":"created","issue":{"url":"https://api.github.com/repos/facebook/react/issues/9245","repository_url":"https://api.github.com/repos/facebook/react","labels_url":"https://api.github.com/repos/facebook/react/issues/9245/labels{/name}","comments_url":"https://api.github.com/repos/facebook/react/issues/9245/comments","events_url":"https://api.github.com/repos/facebook/react/issues/9245/events","html_url":"https://github.com/facebook/react/issues/9245","id":216519160,"number":9245,"title":"RFC: Throw in CommonJS entry points if NODE_ENV is not \"development\", \"test\", or \"production\"","user":{"login":"gaearon","id":810438,"avatar_url":"https://avatars0.githubusercontent.com/u/810438?v=4","gravatar_id":"","url":"https://api.github.com/users/gaearon","html_url":"https://github.com/gaearon","followers_url":"https://api.github.com/users/gaearon/followers","following_url":"https://api.github.com/users/gaearon/following{/other_user}","gists_url":"https://api.github.com/users/gaearon/gists{/gist_id}","starred_url":"https://api.github.com/users/gaearon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gaearon/subscriptions","organizations_url":"https://api.github.com/users/gaearon/orgs","repos_url":"https://api.github.com/users/gaearon/repos","events_url":"https://api.github.com/users/gaearon/events{/privacy}","received_events_url":"https://api.github.com/users/gaearon/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":53,"created_at":"2017-03-23T17:56:56Z","updated_at":"2017-10-04T19:02:27Z","closed_at":"2017-10-04T19:02:27Z","author_association":"MEMBER","body":"Whether it's the best way to do it or not, the fact is we rely on `process.env.NODE_ENV` checks to tell if we're in a production environment or not. This catches people by surprise because the default build of React is the development one, and so they often ship slow and large development bundles to production.\r\n\r\nThis gives an advantage to libraries that ship without a development mode at all. We could do this too. However, I think that this would be a net loss for the ecosystem. Having a way to differentiate between debug and release builds is possible on every native platform, and we should find a way to preserve this distinction on the web. The UX vs DX compromise is a false and unnecessary choice in this case.\r\n\r\nSince React CommonJS entry points rely on the distinction, I propose that we don't allow any empty or custom `NODE_ENV` values. If `NODE_ENV` is nether `\"development\"`, `\"test\"`, or `\"production\"`, we throw a hard error. **This might not be the best solution in long term but at least it is consistent with how we are treating the flag now.** We could then [add React-specific aliases (`REACT_ENV`) for finer grained configuration or for people who use `NODE_ENV` for different purposes](https://github.com/facebook/react/issues/9245#issuecomment-288809950). Still, in my opinion, there should be no default: you need to pick the environment you’re working in.\r\n\r\nThe error would link to a page that provides an exhaustive list of how to configure `NODE_ENV` in different environments, as well as possible workarounds (use the right UMD build). For UMD builds, we will rename them to `react.development.js` and `react.production.min.js` so that the distinction is more useful. This is where people inexperienced with build systems start anyway so I don’t think we’ll hurt beginners.\r\n\r\nI know this is probably going to be very controversial. I believe explicit opting into either mode is the right decision, but it will undoubtedly annoy people. What do you think?\r\n\r\n**Update: perhaps it is better to [just go with `REACT_ENV`](https://github.com/facebook/react/issues/9245#issuecomment-288813823) instead of `NODE_ENV` for everyone.**"},"comment":{"url":"https://api.github.com/repos/facebook/react/issues/comments/334257488","html_url":"https://github.com/facebook/react/issues/9245#issuecomment-334257488","issue_url":"https://api.github.com/repos/facebook/react/issues/9245","id":334257488,"user":{"login":"gaearon","id":810438,"avatar_url":"https://avatars0.githubusercontent.com/u/810438?v=4","gravatar_id":"","url":"https://api.github.com/users/gaearon","html_url":"https://github.com/gaearon","followers_url":"https://api.github.com/users/gaearon/followers","following_url":"https://api.github.com/users/gaearon/following{/other_user}","gists_url":"https://api.github.com/users/gaearon/gists{/gist_id}","starred_url":"https://api.github.com/users/gaearon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gaearon/subscriptions","organizations_url":"https://api.github.com/users/gaearon/orgs","repos_url":"https://api.github.com/users/gaearon/repos","events_url":"https://api.github.com/users/gaearon/events{/privacy}","received_events_url":"https://api.github.com/users/gaearon/received_events","type":"User","site_admin":false},"created_at":"2017-10-04T19:02:27Z","updated_at":"2017-10-04T19:02:27Z","author_association":"MEMBER","body":"I've gone back and forth on this and currently I think it's too much churn for the ecosystem for little gain. Quoting myself from https://github.com/facebook/react/issues/6582#issuecomment-334012889:\r\n\r\n>I just feel like this ship has sailed. A ton of libraries in the React ecosystem already rely on `NODE_ENV` for better or worse, and changing this will involve a ton of churn. What’s worse, if we change it but people don’t update their configs, their code will silently fail to dead-code eliminate in popular bundlers like Webpack.\r\n\r\nAlso, as I mention in https://github.com/facebook/react/issues/7512#issuecomment-334137262 regarding `staging` environment:\r\n\r\n>React 16 ships with separate entry points for production CommonJS bundles in `react/cjs/react.production.min.js` and `react-dom/cjs/react-dom.production.min.js`. You can alias `react` and `react-dom` to these bundles to force a production environment even if `NODE_ENV` says otherwise.\r\n\r\nSo there is a workaround."}}
{"actor":{"display_login":"gaearon"}}