React: Explore encouraging users to not ship DEV mode to production

For reference: https://github.com/facebook/react/pull/8782

For context we already warn if we detect that you've minified a DEV version of React: https://github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91-L98

As far as we can find similar heuristics to notify users, and maybe even more aggressively pop up a DOM dialog, we should.

I also want to make it clear the warnings we provide can significantly improve performance if people pay attention to it. This thread explains some rationale for why it is difficult to deploy this after the fact if it is not the default.

I'd also like to chime in with a suggestion of a single console.warn if renderToString is called in dev mode. Obviously, in most situations renderToString is called in node, where we can't alert or pop up a DOM dialog.

Unfortunately, I'd really like to be able to detect not just if NODE_ENV is set to production, but also if process.env.NODE_ENV has been compiled out. Does anyone know of a way to do that?

Thanks for the thread @sebmarkbage and I acknowledge the difficulties of deploying after the fact. I'm also appreciative of the current warnings. It appears that some developers may not check the console output of their deployed sites as often as they could. It's a good first step however.

As far as we can find similar heuristics to notify users, and maybe even more aggressively pop up a DOM dialog, we should.

I'd be grateful for improvements to the heuristics used to notify users. A more aggressive DOM dialog would go a long way in helping. It would ensure the site continued working for end-users but provides an active hint that there are low-hanging perf fruit developers can pick.

The alternative is that we find a way to fix this at a build-tool / ENV level as mentioned in the original post. That would avoid any DOM-injection being necessary.

Injecting any messaging into the DOM seems dangerous and a little too assuming. That opens up the possibility of end users getting unexpected and confusing alerts which seems unacceptable IMO.

@thelarkinn was proposing that we tried to standardize on ENV configs being required to better facilitate detection of messaging like this

This feels like the ideal space to address this. It's a build issue and should be, if possible, addressed by the build tools.

Anecdotal: Warnings in the console have been gone unseen (or ignored) in the past. I have no hard numbers here, but I think console-based warnings are not enough. I agree with @addyosmani that a DOM-based warning would go a long way.

@surma maybe they should use console.warn or console.error for better visibility 😉

I don't see how it would be acceptable in any scenario to inject content into an application only when it's running in production. You're making a huge assumption that the message would be caught before the application was pushed to actual users, where the message could potentially hurt UX in a major way.

Btw, we're going to be add more comprehensive error handling support in Fiber so that you can replace components that have failures (thrown errors) with custom error views. Even in the default scenario we're likely going to be very aggressive, and just remove that component from the tree if it errors so you're really going to want to have a custom error UI for your users anyway.

We might be able to trigger such an error for this warning.

I honestly don’t think that console.{error,warn} over console.log would have changed anything. As I said, that story is anecdotal.

I am also not saying that showing a DOM dialog is _the_ solution. It’s something I’d personally be comfortable with, though. If staying in dev mode has negative impact, at least users would know that _something_ is wrong and probably starts hitting the “Help” button or something.

Bottom line: I think frameworks need to get in the developer’s face at some point. I’d love to brainstorm on this to see what steps and compromises framework authors are willing to take to prevent people from deploying in dev mode in the future.

What if React just doesn't work at all unless you provide an environment, regardless of whether it's development or prod? That way there's a conscious choice being made one way or the other.

About the message injected in the DOM, it could be disabled using a global or something. No big deal IMO. If you disable it, you kind of acknowledge you know what you're doing.

Problem with a console message is that sometimes people log a lot of things, or have other warnings they ignore, and it's easy to not see that first console message past the scroll...

With a mandatory env, inevitably boilerplates etc. will set the env var so you can just start using it I'm afraid :/

I honestly don’t think that console.{error,warn} over console.log would have changed anything.

Do you think its a problem with developers just not checking the console, or the console being overloaded with warnings? Could this be (partially) addressed with a more general approach regarding developer education?

I am also not saying that showing a DOM dialog is the solution. It’s something I’d personally be comfortable with, though. If staying in dev mode has negative impact, at least users would know that something is wrong and probably starts hitting the “Help” button or something.

I understand that, but I'm just saying I don't think its a solution let alone the solution. Its good that you're comfortable with it, but I think it's better to err on the side of caution and assume that most people don't want unexpected errors displayed to their users.

Bottom line: I think frameworks need to get in the developer’s face at some point. I’d love to brainstorm on this to see what steps and compromises framework authors are willing to take to prevent people from deploying in dev mode in the future.

I am 💯 for getting in the developer's face, but it's important to do it at the right place. To me, that's the build step, not production.

About the message injected in the DOM, it could be disabled using a global or something. No big deal IMO. If you disable it, you kind of acknowledge you know what you're doing.

Having it enabled by default is just as bad as not making it configurable: the default behavior could result in unexpected behavior for the end user. If anything it should be disabled by default, but then that defeats the entire purpose since developers could just fix the initial problem once they're aware of it.

Problem with a console message is that sometimes people log a lot of things, or have other warnings they ignore, and it's easy to not see that first console message past the scroll...

I totally get that, the console can get crowded and it's easy to miss stuff. But it's crowded for the exact reasons I'm arguing: it's the place the provide developers with feedback or errors. It's out of the way of the user experience, which injected messages aren't.

Makes sense, I understand the reasonning.

Well maybe make the thing pop out using console formatting would be something at least.

The problem is almost nobody looks at console in production. You can use any font there and people won't notice it.

However if we make it show a message by default in production as a breaking change (in 16 or 17) then it would be hard to miss. I mean, it would happen the first time you would try to deploy it (for new users), and existing users should be reading release notes when updating to a new major. So I think it's doable as long as we are super explicit about it and it's impossible to miss the message.

The problem is almost nobody looks at console in production. You can use any font there and people won't notice it.

I can only comment on the Chrome team's experience with this, but I'd concur. Most folks will notice console messages during their iteration workflow but a far smaller % look at warnings on production sites and fewer act on them.

However if we make it show a message by default in production as a breaking change (in 16 or 17) then it would be hard to miss. I mean, it would happen the first time you would try to deploy it (for new users), and existing users should be reading release notes when updating to a new major. So I think it's doable as long as we are super explicit about it and it's impossible to miss the message.

Thanks for being open to a change like that @gaearon. What would it take to get agreement on trying for a message by default in a future release? 😄

I agree that console warnings aren't the solution & a page-visible warning is much better.

The page-visible warning could:

• Alert the dev that the site is in dev mode
• Link to the docs on the benefits, and how to ship without it
• A link to disable the message for… I dunno 2 hours?

Disabling the message is important, as it may be interfering/covering something on the page. Since this setting would be stored in localstorage, the warning will still appear on the live server because it's a different origin.

Yeah, it's pretty horrible if real users see this message on live sites, but it feels like the kind of problem devs will be encouraged to fix, whereas some seem to be happy to live with the performance issues of dev mode.

If the first time I saw that warning (the insert into DOM one), was in production, I would be fairly upset. The warnings need to happen ahead of time.

@rtorr my suggestion is that it happens whenever the site is in dev mode, so it should be seen ahead of time unless I'm missing something?

@jakearchibald sorry for the confusion, my reply was not directed at yours. I just want to point out to the thread that if we were to use the 'insert into the dom' solution, we should be very careful and make sure users know before they push a thing (some how, I have no good idea here).

I just see some dev forgetting a setting or something and management freaks out. Is that possibility worth it for the consequences of having dev mode in production?

A DOM based warning that I have to constantly disable is not okay, it must be possible to disable it forever, and maybe it should never show at all for localhost.

A thing that just hit me if it would be possible to have some kind of a flag in the browser that you have to enable to activate the devtools (maybe a big overlay in them with "Are you a developer? [Yes/No]") that the page can detect and only show the warning for developers. Worded correctly it might help with self-XXS attacks as well.

A DOM based warning that I have to constantly disable is not okay, , it must be possible to disable it forever

Sites launching with dev-mode on is also not okay. Maybe the message only needs to be dismissed once per day? But the longer the period, the more likely it is that'll it'll end up on live. If it can be disabled forever, we're right back where we started.

I also don't think an unintended dom node in production is OK.

I think that either way, we will always have an edge case. If this problem happens all of the time, then maybe the delivery of dev mode is wrong. Although not ideal in a perfect world, but if we find prod mode this important that we are willing to modify someone's application, maybe it should be default and dev mode should be opt in.

@rtorr

I also don't think an unintended dom node in production is OK.

Why? (I'm not saying you're wrong, would just like to hear your reasons)

Maybe adding a setting to define prod Domain. If prod Domain is not set then we always get the warning about DEV mode (with a request to set Domain URL), if it is set then we only get warning when the URL matches with prod domain. We could even bind any service we want to notify devs

I'm glad there's constructive discussion here. There are two solutions here that I can see solving the problem. Webpack could force specifying NODE_ENV which React could then use to more easily avoid folks shipping DEV to PROD, but that would be a breaking change to Webpack. I'm talking to Sean now about how feasible something like that could be for Webpack 3. Keeping the React + Webpack stack beginner and perf friendly is something I know both camps care about.

The second (DOM injection idea) is something React could do and as Jake mentioned, balance the UX by allowing the message to be shown once a day or be dismissed. It's a one line change to fix the issue then you just have to redeploy. I completely empathise with not wanting management to freak out.

If we're to get more React sites shipping the far faster experience FB worked on to prod something might have to give. If anyone has better ideas please suggest them.

@jakearchibald

Why? (I'm not saying you're wrong, would just like to hear your reasons)

Back to my comment above, unless we are able to let developers know ahead of time (which seems to be the actual problem to solve), I find it kind of extreme to devalue someones product by displaying a warning to developers on their production page. In a lot of cases this could potentially hurt the product more than the performance of dev mode.

No matter what we do, someone is going to ship whatever is default into production, why not make production default? Why not improve dev mode to the point where it's not that big of a impact?

@rtorr https://twitter.com/sebmarkbage/status/820054247496503296

@jakearchibald yeah, I see both sides have problems. I have faith of the people in this thread to come up with something good, even if it's what you are proposing. Y'all are great FYI. Maybe extreme is the answer.

Could you not insert the DOM node warning if the user is running React dev tools so normal users don't experience it?

@jakearchibald

Sites launching with dev-mode on is also not okay. Maybe the message only needs to be dismissed once per day? But the longer the period, the more likely it is that'll it'll end up on live. If it can be disabled forever, we're right back where we started.

When the site launched someone took a decision that it was "ready" so while it's bad it is not a catastrophe. However having (possibly, I don't know the exact numbers) hundreds of thousands of devs having to dismiss a site-destroying (A DOM warning must be treated as that as you have no idea of how it interacts with the rest of the site and if the site is usable with the warning visible) warning five or even just one time per day is a catastrophe. Most devs have a correctly set up build-chain (custom, create-react-app or other) and have no use at all for that warning, they need to be able to get rid of it.

@dan-gamble I beleave devs not using React Dev Tools is the most urgent target for this warning though.

@Pajn Potentially, i don't think just because you download a Chrome extension it automatically makes you conscious of the prod / dev switch

@dan-gamble No, of course not. But there are people that develops a whole app without it which I think indicates that they don't use dev tools much and are therefore less likely to see the current warning for minified code.

I don't usually add to such a long discussion when I feel like the point has already been brought but this I have to agree with and want to emphasize this point: React touching the DOM and warning me I'm using a dev version would be a big mistake. A far as I know there is no precedent for that in any other framework.

Imagine all of the tutorials, all of the playgrounds, all of the little side projects that use dev mode to teach React. Every single little test site that I throw together to explore something fun in React, or try to isolate a test case. If React through up a warning on every single one of these sites that I had to manually disable I would be incredibly mad. It would feel like an overbearing parent and actively discourages you to use React because whenever you try to do something new it slaps you on the wrist.

Even doing it every 2 hours? No thank you. A constant nagging like this is certainly going to discourage users from developing in React and I honestly think it would push people away to adopt other frameworks. Maybe that's what the Chrome devs want?

Not to mention the fact that yes, this will slip into production somehow, and it's already hard enough to convince certain teams to adopt React and that's just more ammo for them against it.

The thing I love most about React is that that it doesn't do anything until you call ReactDOM.render(...) and when you do that, it only puts stuff into the DOM where you told it to. That's why it's such a good, isolated, functional library.

Do we also need to detect if people shipping an unminified bundle? What about if they aren't caching when they should? What about when they haven't configured nginx optimally? Or don't use shouldComponentUpdate when they should? Or are unnecessarily rendering everything when they don't need to?

There are several reasons for bad performance and to blame it solely on React's dev mode is wrong. When you deploy a site it's totally expected that you understand how to deploy an optimized site. I'm not saying there aren't things we can do, but the core reason for this is issue is benchmark authors not doing their due diligence and we shouldn't have to pay for that. We need to find another way to call that out.

I meant to follow-up with what I think is the right solution: put these kinds of restrictions in the tools. Making sure that webpack or whatever tool you use to build your site for production is where we should force these checks and I'm down with any kind of restrictions we want to place in the build process.

With regard to webpack forcing a NODE_ENV setting (maybe there's an issue for this in their repo already), wouldn't that make it harder to use libraries that don't rely on env settings?

Or is the idea that it would detect NODE_ENV use and force it only if the code uses it?

Let's not get too hung up on the "2 hours" thing. It could be any period of time as long as it works.

Additionally, local storage events means it would only need to be dismissed once per origin. If you have multiple demos on one page, dismissing one would dismiss the others.

If the warning does slip into live, it's loud enough to warrant a quick fix - one that benefits users. If we're worried about how React looks in public, we really want to avoid unnecessary slow-down like this.

Sure, this wouldn't detect bad caching headers etc, this is about detecting "dev mode" only. Also "slippery slope" arguments aren't helpful.

I don't think moving the problem to build tools is useful, as you'll have the same problem if devs use a different build tool, or fail to put that into production mode. Dev mode frameworks already produce console warnings, and that clearly isn't working.

This isn't just about benchmarks, it's about real websites, running slow for real users, because a switch wasn't switched.

@jakearchibald Thanks for the rational response to my emotionally-charged one. I do think that it is a valid point that there are many reasons a site might be slow with React. I'd like to see a way we can suggest performance improvements that's better than a crude check for dev mode and an in-browser warning. If we had tooling to analyze a React app and provide serious suggestions for performance, from everything like dev mode to too many rerenderings, that would be a lot more useful. A generic tool like that can be hooked into any pipeline, be it webpack, browserify, etc.

This is the main thing I wanted to say though: some days I will use React dev mode across 5-10 different places, like jsbin, tutorials, and even throwing together a small test site and opening it with the file:// protocol. A forced in-browser warning is hostile to this sort of flexible development which is what the web so excels at. I'd be seeing these warnings everywhere because I'm learning React across domains on the web.

If the warning does slip into live, it's loud enough to warrant a quick fix - one that benefits users. If we're worried about how React looks in public, we really want to avoid unnecessary slow-down like this.

Even allowing the possibility of a developer-specific warning being displayed to end users seems unacceptable to me. A slow site is one thing, but a message like this could undermine user trust, especially for security-focused sites (would you be happy if your banking site was displaying cryptic errors all of a sudden?) Would Google be OK with all of their users suddenly getting this warning, even if only for a moment?

Additionally, local storage events means it would only need to be dismissed once per origin. If you have multiple demos on one page, dismissing one would dismiss the others.

You can't rely on localStorage to dedupe this. There's no guarantee that localStorage (or any other local persistent data) will not be cleared at any interval.

edit: Also, by only displaying the error once every {INTERVAL} you've now made it far more difficult to reproduce and debug as it's not deterministically reproducible.

There are 2 cases that need to be solved:

• Prevent falsy benchmarks, performance tests: Easily solved with a big big console message.
• Prevent shipping DEV to production sites: People don't open devtools in prod.

Arguments against touching the DOM are convincing.

If there is a big, flashy, obvious console warning, chances are that before shipping to production people will use the dev version and see this really obvious console message. Or maybe some code has already been shipped to production, but for another project they will use the next react version with this impossible to miss console message. Maybe they will remember that site they shipped to production and check if DEV is enabled there.

The console message would be educationnal, like, anyone who does React development knows that there's something really important about DEV, and they see it everytime they use React for development.

I was hesitant about https://github.com/facebook/react/pull/8782 because people generally don't like warnings they can't get rid of (see https://github.com/facebook/react/issues/3877), but considering the alternatives it might be an acceptable solution.

Curious. Would localStorage usage invoke the EU cookie law on a site that isn't otherwise covered by it?

If informative warnings during development is a good idea, then why aren't other libraries doing it? Well, one reason is for problems like this. If others wanted to do this should they also pop up similar UIs? Do you have to close all of them?

It seems to me that it would be ideal to have something more central to handle this.

Perhaps Chrome could have a development mode? Libraries could tell the host that they're in development mode and then Chrome could add a badge or pop up to indicate that.

Makes me think the react devtools extension could be leveraged to display a notification or something obvious when opening a page using react in dev mode maybe ?

@sebmarkbage

If informative warnings during development is a good idea, then why aren't other libraries doing it?

I guess someone needs to be the first. Angular has a similar problem, with stuff like http://code.gov launching in dev mode. If React starts catching this stuff where other frameworks don't, I'll be pushing for them to make similar changes.

I'll be pushing for them to make similar changes.

@jakearchibald are you suggesting that each framework should provide their own warning? I don't think setting the standard for frameworks/libraries providing their own development warnings in production is a great idea. Shouldn't we be trying to standardize on the platform? As mentioned by @sebmarkbage

Perhaps Chrome could have a development mode? Libraries could tell the host that they're in development mode and then Chrome could add a badge or pop up to indicate that.

I think this is a great idea. Precedent: Safari has a separate mode that you must enable to access DevTools. If Chrome did the same then it could also safely add an indicator for DEV mode and an API to trigger it. This indicator would only be visible to developers so it wouldn't disrupt user experience.

Isn't waiting for browser vendors to implement such a thing going to take time ?

@jide yes, but it's more important to address this problem correctly than quickly. Also, it can be implemented in a single browser before considering standardization efforts (if necessary).

@aweary

are you suggesting that each framework should provide their own warning?

Given that each framework provides their own dev mode (and that mode may be very different between frameworks), it seems entirely fair that the framework should implement the warning in a similarly unique way.

Browsers have gone to some lengths to avoid exposing devtools to the page. If we're making devtools the barrier to entry here, we're going to miss a lot of users that a DOM warning wouldn't miss. A DOM warning seems not only simpler, it has fewer platform dependencies, and will reach more devs. Simpler & more effective sounds like a win.

@gaearon On the Chrome DevTools side, we've been brainstorming a live "violations API" that web platform & framework authors could use to signal important warnings. These would be presented somewhere like the upcoming Audits panel refresh. It sounds similar to your ask and could be used to trigger a warning on DEV mode detection.

For this particular issue, you may be after something a little louder than what we were originally planning. A violations panel, similar to console log messages, requires you to know a panel is going to provide insight. Perhaps there's additional UX room for something that displays a very visible page overlay lower down the page which frameworks could standardize on messaging for. Looping in @paulirish and @s3ththompson for their thoughts after the holiday weekend.

Fwiw, my guess is this API won't be ready for another few months. When it is, it will only be available in Canary initially and then 6-7 weeks later it might make it's way to stable.

A DOM warning seems not only simpler, but more effective.

I'm in agreement with Jake on this one. Let's keep chatting about the DevTools solution, but I'd also like to figure out what React might be open to doing as a fallback in case the API doesn't end up fitting your needs or is further out timeline wise.

Given that each framework provides their own dev mode (and that mode may be very different between frameworks), it seems entirely fair that the framework should implement the warning in a similarly unique way.

@jakearchibald you realize that setting that standard means pages utilizing multiple frameworks (or libraries that followed in suite) could result in an arbitrary amount of non-deterministically rendered cryptic warnings being displayed to end users?

Browsers have gone to some lengths to avoid exposing devtools to the page.

And I'm sure the reason is at least partially because developer-specific messaging should not be exposed to end users.

A DOM warning seems not only simpler, but more effective.

Nobody is arguing against the simplicity or effectiveness of the solution. It would work, but at the expense of compromising the user experience. Speed isn't the only thing that can negatively affect users.

Fwiw, my guess is this API won't be ready for another few months. When it is, it will only be available in Canary initially and then 6-7 weeks later it might make it's way to stable.

@addyosmani if its a better solution, I don't see how that would be an issue. Any changes to React would be in a major release, which I think is TBD as far as release timing goes anyways.

The solution decided upon will potentially affect all future development. A matter of weeks vs months in that context is acceptable IMO.

I understand that some developers feel invaded if a framework injects something into their DOM that they didn’t put there themselves. But I feel like a banner at the bottom the page that says “This site is in DevMode” would be a great solution to this that doesn’t have a big impact on the user’s experience. I’d like to understand why a lot of people think the opposite.

@aweary: If a “security-focused” site ever launches in DevMode, they shouldn’t be trusted until they fix the issue. “DevMode” could include all kinds of security-related shortcuts like disabled CORS checks or exposed template source code etc. If a site is security-focused, this _must_ not happen.

(I realize that “DevMode” has a very specific meaning in React, but I am trying to assume a non-developer’s perspective here)

@aweary

you realize that setting that standard means pages utilizing multiple frameworks could result in an arbitrary amount of non-deterministically rendered cryptic warnings being displayed to end users?

I absolutely realise that. A page with multiple frameworks in dev mode will be severely damaging the user experience for no good reason. It seems you'd rather it goes unnoticed and unfixed. I'd rather it's so bad for non-developers (visible messages targeted at developers) that the developer fixes it promptly, creating a much better user experience.

Speed isn't the only thing that can negatively affect users.

I don't see anyone claiming otherwise? I'm pretty sad about this kind of reaction 😞

It seems you'd rather it goes unnoticed and unfixed

@jakearchibald that's kind of a strange conclusion, I don't think I'd be spending my free time here talking with you if I didn't want this to be fixed? Just because I don't agree with your solution doesn't mean I'm resigned to leaving it unresolved. That's really unfair.

I'd rather it's so bad for non-developers (visible messages targeted at developers) that the developer fixes it promptly, creating a much better user experience.

That's what I think is fundamentally unacceptable: you're explicitly punishing users first.

If a “security-focused” site ever launches in DevMode, they shouldn’t be trusted until they fix the issue.

@surma dev mode is not inherently insecure, but regardless it's stepping over the line to assume it's OK for you to communicate that to users.

I don't think a solution that requires opening or enabling dev tools is sufficient. For this to get noticed it needs to be visible to QA, management and possibly end users. Developers will be too used to seeing this. Similar to how problematic ssl configurations are highlighted. It doesn't need to be much but enough to be noticable that someone will ask about it and then get it fixed.

Injecting into the DOM is problematic for many reasons. It's a bit more feasible for React since we're a DOM library and have DOM entry points. It's harder for libraries that are not DOM specific and might run in a worker.

One thing we might be able to do is change the favicon as long as we provide a way to override it explicitly. Many sites already have separate favicons for development mode.

We need to figure out a default experience for handling errors in React which may not be able to keep the DOM in place. The current default implementation in master deletes React content from the tree if an error is thrown. That is also invasive.

If we had a way to detect that you're not in development mode we could trigger that error mode. We really need a solid way to opt into a development mode permanently then.

Similar to how problematic ssl configurations are highlighted.

This is exactly the kind of thing I think would be perfect. Users are already used to browsers providing security information about sites they visit, performance information isn't a huge jump from there. Plus, it would be consistent for all frameworks/libraries that report potential performance issues and would not directly interfere with the user workflow. 👍

I like the favicon idea : Noticeable, works without devtools or extension, noticeable by everyone, does not do harm to users, can be animated to draw attention, annoying enough to make devs want to disappear.

What about making DEV mode opt-in?
We err on the "good UX" side, because bad DX is easier to notice (and IMHO for issues like this users should "win" because they can't choose, while devs can).
I'm sure some frameworks already do this (like Relay if I recall correctly).

Proposals on how to implement it:

• enable development mode only if NODE_ENV is explicitly set to development
• enable development mode if the global __DEV__ is === true
• export a debug tools module to be enabled in userland

The first seems the best because the other two may be hard-coded without a guard (such as an if(NODE_ENV === 'development') statement) and thus be shipped to production anyway.

@mattecapu See my second comment regarding. https://twitter.com/sebmarkbage/status/820047144677584896

If there is a similar way to enforce that developers start out by running in DEV mode then it doesn't matter what the default is. But it is really bad if you fall behind.

There's a lot to comment on here, and I have thoughts, but I'd like to weigh in specifically on just the question of how to disable a dev warning.

I'm not a huge fan of a button that disables a DOM warning for a set amount of time in one particular browser. As @jlongster points out, it's a pain for devs if it happens frequently. But more importantly to me, it introduces browser-specific variability in behavior, which could easily lead to "but it works fine on my machine" irreproducibility of bugs.

I'd prefer a parameter sent to render that lists domains that are considered dev boxes, with a default value of ["localhost", "127.0.0.1"]. It would look something like this:

React.render(<App/>, 
  myDiv,
  () => { console.log('finished render!'), 
  { devDomains: ["localhost", "devbox.mycorp.com"] }
);

If the current domain is in the list, then the dev warning never shows up. Otherwise, it does. Under this regime:

• Using dev build on your local machine using localhost or 127.0.0.1: No developer warning ever, and no developer action needed.
• Using dev build on a dev machine using another host name: you get the DOM warning until you add the domain name to the list passed to render. Thereafter, you never get the DOM warning.
• Using the dev build on a prod machine: you get the DOM warning until you switch React to the prod version.

The one thing that worries me about this solution is that it might lead developers to leave in a list of all their dev server domains in the code, and that code may make it to production. For companies that consider their dev server domains to be a secret, that'd be a problem. Thoughts?

@aickin the problem with that approach is that it requires users to be aware of the configuration and, in turn, the problem it's solving. The issue is that people aren't aware of the dev/prod distinction in the first place.

Edit: nevermind, I see, there's still a DOM warning in development.

Server side environments fix this by showing a "special" error page that includes debug details and also tells you to not to serve it in production.

Since we plan to make React "fail fast" and unmount views unless you provide a custom error boundary, we might as well add a default "red box" error boundary in development that acts as an educational page.

Then, the first time the user has a bug in production, they will see a special verbose error message. This could be an opportunity to educate about the DEV build.

But I feel like a banner at the bottom the page that says “This site is in DevMode” would be a great solution to this that doesn’t have a big impact on the user’s experience. I’d like to understand why a lot of people think the opposite.

Most users dislikes web apps if they know that it's a web app, why? Because a previously common mentality of the web was that when it shows up on the screen it's done, no matter how bad it behaved and users have learned that the web is bad. However it's perfectly possible to create a great UX on the web, but to do that I must own the DOM. If someone injects random banners at arbitrary places the wrong element may start to scroll, or it may cause the whole screen to repaint on scroll or it may interfere with for example drag gestures or something else. The point is, as long as that banner is up I can not develop because I can't know that the experience is the same when that banner is gone.

As a framework solution I really like the favicon idea, it does not hinder development, it does not look to strange for users, it does not possibly destroy the UX but it will get noticed. However, it really only works for a single library or framework at the time and it does not work at all for libraries that run in workers. The real solution is a good way to do this through the browser that can support multiple frameworks and libraries and can be accessed from all contexts.

Another solution that supports multiple frameworks and libs and is more clear, but does require a permission request, is to show a browser notification.

Here's an idea: update the getting started docs on react's homepage to push create react app more heavily. And stress the importance of npm build in those docs. We don't need a DOM warning, we need awareness.

I think @ropilz touched on this earlier in the thread with his "_..we could even bind any service we want to notify devs.._" comment, but it may have gone unnoticed (or not acknowledged).

As I understand it, the fundamental problem being solved here is

• to somehow alert _developers_ when production _end-users_ experience a site running in dev mode
• we can't rely on devs seeing console.log messages (or even DOM warnings for that matter) in production, _unless_ those devs are actively using the production site themselves (or we're relying on end-users, QA/support teams etc. to report these warnings back to the developer)
• there are (valid) UX arguments _against_ showing end users a DOM visible warning that is intended for developer audiences.

What if there was something analogous to CSP's report-uri, for frameworks to send dev mode warnings to, rather than showing a warning in-situ on the site where they would be visible to end-users?

Obviously there are a number of things to be considered, such as:

1. Such reporting would ideally be ON by default, but what would the default report-uri be? (would we expect each framework to host their own free service, similar to https://report-uri.io? (this _may_ possible for large, company-sponsored frameworks like React & Angular; but certainly impractical for smaller open-source frameworks like Preact, Vue etc.)
2. Once a warning has been reported, how is the site owner/developer notified? (perhaps a good way for non-devs to get involved with a project, by volunteering to monitor these reports and help track down/notify the maintainer?)

I fully admit this suggestion is only a thought-bubble, and I haven't considered how practical this would be or how it would actually work; but I wanted to raise it as it seems to me that the challenge of 'reporting on production issues' has already been partially solved for CSP/HPKP reporting, and perhaps we could explore something similar here?

It's important to take a step back and realize React is a framework. You must not:

• Modify the DOM to present something visually just as a reminder for developers. There is no way this works well out of the box unless you understand and develop something that can work in all environments without hindering the developers and losing their user's trust should it happen to pop up in production (if my experience is any indication this will happen quite frequently and many won't be able to deploy a quick fix to turn it off).

• Modify the favicon. The favicon is annoyingly cached, used for bookmarks, saved web app icons on mobile devices if others are not specified, etc. This runs the risk of an accidentally (or on purpose) production deployment into dev mode erasing a brand's logo.

• Browser notifications. When you are being looked at, you are likely being looked at by a user. Popping up a notification is going to request browser permissions and pop up strange things that users will not understand. The assumption that these would be mostly seen by developers, in my experience, is exactly inverse and possibly trust ruining for users.

It's not React's job to babysit developers. I propose either:

1. Make development mode opt in. When the developers realize they can't debug something they'll look up how to turn it on (which needs to be documented everywhere). No, it's not React's job to tell them to turn it back off. Their problem.

2. Leave it to a simple console.log message (and this must be disable-able). Let developers find it and handle it. If they don't, oh well. You can't reach into every organization and make them do things correctly. It's just not scalable.

I have to disagree with touching the DOM to display a warning. It looks easy and simple for React because it's a DOM library, but imagine if all libraries have to display their own warning in the DOM. It will be a total mess.

There's so many libraries that developers use that probably have their own dev mode. I think setting process.env.NODE_ENV to production has already been a common standard in bundling modules for browser. This is what we need to improve the awareness of.

I do agree that React docs doesn't prominently show that there is difference between dev and production build. When you open the docs, you have to go through Advanced Guides to read the difference between dev and production build. The title is Optimizing Performance, something that beginners definitely won't take a look because they use React because they heard that it's fast. I think the docs could be improved to have another docs titled "Using React in Production" or similar in Quick Start section.

Beginners doesn't usually read Advanced Guides but they will open some links in Quick Start if the title is clear enough and looks important. I know I did because that's what I do when I start learning React. I didn't read the getting started guide, but I do read some pages in Quick Start section.

Another approach we could take is showing warning in console when React is used in dev mode with link to fix that point to the docs. Opening console in production for developers is unusual, but in local env when developing they will certainly open the console. This way when developing locally, they will aware that they need to do something before publishing to production.

http://code.gov launched despite console warnings. This is exactly the kind of thing we should aim to prevent. (That site is Angular, but the same applies to React)

Here's the issue for code.gov if anyone wants to reach out to them (or send a PR): https://github.com/presidential-innovation-fellows/code-gov-web/issues/221

Angular 2 is running in the development mode. Call enableProdMode() to enable the production mode.

I've never used Angular 2 before (which makes me beginner in this case). My initial reaction after I see the warning is I just try calling enableProdMode(). It doesn't work. I think the console message for Angular case could be improved. Instead of relying on magic, they should point to the docs.

Opening the Angular docs, I don't see anything about production build. I think this is a problem for both Angular and React. They both use dev mode, but they don't tell people up front in the docs on how to disable it. That's why improving the docs could go a long way on educating developers

I'm not against showing user warning when developers make "mistakes", but injecting some random DOM element is just intrusive. I love how browsers handle HTTPS problem where the browser have dedicated UI to show that the site is insecure. We don't have one for performance related status. Given rising concerns about web performance in general, I don't see why browser vendor doesn't come up with ways to tell user that the site they're visiting sucks.

This should be addressed at the tooling level, so possibly webpack and Babel can notify the developers of the benefits of setting a NODE_ENV.

@pveyes Agreed, I've made the same point to the Angular team.

@matthewp there's a much older issue about this https://github.com/presidential-innovation-fellows/code-gov-web/issues/129 and the Angular team have reached out directly and given them the fix - there seems to be little desire to apply it. Question is, would a DOM warning have made this fix more urgent, or have prevented it launching in dev mode to begin with?

Question is, would a DOM warning have made this fix more urgent, or have prevented it launching in dev mode to begin with?

More than likely they would see the warning in development, Google how to disable it, and disable it. Then deployed it in dev mode without realizing it in the future because they forget. During development you want it to look like production so you can't have some random chunk of DOM being inserted. You can't have a QA or staging system seeing this either as it wouldn't be indicative of production.

So you end up with a bunch of junk code disabling this thing that screws with the site's UX. It's not like the original engineer who disabled it during development would necessarily remember either; they may have even moved on before it went to production.

I'm not sure how the deployment process works at code.gov but if it's anything like what I experienced as a government contractor than an accidental development mode deployment into production would either:

1. Force a full rollback of the entire deployment (some of which take 6 months to get approval for and bundle in everything from UI changes to server software updates), likely the next day, then you get meetings and follow-up paperwork regarding what happened and scheduling a new deployment window (you'll get asked, over and over again, if the DB scripts or services or whatever were all in dev mode because of a single warning in the UI). I've seen this happen for very minor things. Sometimes you can get exceptions but YMMV.

2. It would get noticed by users, it would get corrected but since it's likely not impacting function would not get updated until the next deployment window. So all users get to see it for weeks or months.

At least that was my experience. Point being, even if a DOM intrusion is noticed immediately after deployment, you don't know what their infrastructure / process is like and it may not be something they can fix immediately (even though they should be able to).

Warning messages will be more noticeable when #7360 (yellow box) gets merged. We could also add a message to the yellow box (call it "React Development Mode Warnings"?).

Opening the Angular docs, I don't see anything about production build. I think this is a problem for both Angular and React. They both use dev mode, but they don't tell people up front in the docs on how to disable it. That's why improving the docs could go a long way on educating developers

It is right on the Installation page:

https://facebook.github.io/react/docs/installation.html#development-and-production-versions

And on Optimizing Performance:

https://facebook.github.io/react/docs/optimizing-performance.html#use-the-production-build

I don't think it's fair to say docs are not upfront about it.

When you open the docs, you have to go through Advanced Guides to read the difference between dev and production build. The title is Optimizing Performance, something that beginners definitely won't take a look because they use React because they heard that it's fast. I think the docs could be improved to have another docs titled "Using React in Production" or similar in Quick Start section.

It is right there, on the very first page (Installation):

https://facebook.github.io/react/docs/installation.html#development-and-production-versions

You're right. Sorry, my bad. I assumed that production build is in different section so I didn't look there and search for relevant title in sidebar instead (and found the Optimizing Performance page). I should've known better.

I'm not really a beginner to React, that's why when I open the docs to verify my assumption - that React docs is not upfront about prod vs dev - I didn't open Installation docs 🙇

No worries. If it's not visible enough I'm open to suggestions for better placement. For example we could make a dedicated page for it (Deploying to Production).

Let's not forget that this issue is a important issue to solve but not the most important issue to highlight. I'm also not convinced it will be sufficient even if highlighted at the very front page because people will see it and browse through, forget about it, and think "I know what I'm doing". So I wouldn't over pivot on the docs thing.

The only real way to address it is by detecting and notifying.

@KrisSiegel The favicon getting cached is a good point. I wonder if we should just switch it after a second or two and then flip it back briefly every few seconds. That way the caching and bookmarking issue is very unlikely to time it at the time of the overridden icon.

I thought JS manipulations to favicon don't get cached but maybe I'm wrong.

I'd argue that the right place to have hooks for this is not Chrome or Firefox, but rather webpack, Browserify, or Rollup.

Building what's intended as a production bundle for React but without enable production mode is just that – a build error. I think the reason there isn't agreement over how to present this at run time is reflective of this not being a problem that should be handled at run time.

@taion I agree. I think this definitely belongs in the build tool, not in the DOM.

I think it should be the build tools place to make the assumption that node env should be set to production for production code. It may not be required for all projects, but I do think it is a good assumption.

If npm run build is ran in the terminal, and the env is not set to production, then you should get a red warning in the terminal along with the default output: env is not set to production, some scripts may be in development mode

Currently I get no such warning from webpack.

Edit: added clarification

Or just set NODE_ENV for you, really.

If console warnings aren't working, I'm not sure build warnings will.

The build should either configure things for you, or else fail if misconfigured for production. At least for React, this _is_ a build time flag.

@jakearchibald I am sure it will still be ignored by some, but at least the warning would be shown to them when they build it, instead of not being seen because the warning is hidden away in the browser console which they may never open in production. Most importantly it gives those with less experience a clue about what they should be doing to make the code production ready.

While many devs will update libraries, it is common not to update webpack and more generally tooling, because a lot of people make the assumption that it just works, and it may be a pain to update webpack and co.

Building what's intended as a production bundle for React but without enable production mode is just that – a build error.

Using a prepackaged version of React from a CDN is also a supported configuration, but there's no build step at all in that workflow. Therefore, a solution to this issue that only focuses on the build would ignore the CDN use case.

I'm honestly not sure how I feel about that; I can see arguments both for and against having dev warnings for React CDN usage.

@taion As someone who supports a build-only solution, do you think this is an important use case to cover?

What do other folks think?

I think the documentation there is pretty clear that you should use the .min.js bundles for production. Maybe it could use a bold, a bigger font size, something like that. But if someone is using the unminified React bundle in production for their website, they have other problems anyway.

I think the documentation there is pretty clear that you should use the .min.js bundles for production.

Agreed, but the page is also pretty clear on how to configure your build tool for production if you include React as an npm package. I think the whole point of this issue was to try to create a pit of success for folks who don't carefully read that page of documentation.

It sounds like you may disagree, though, and that you think that using the dev build from the CDN is not an important case to prevent with a more aggressive dev warning. Is that a fair summary of your position, or am I missing some nuances?

I think the CDN+dev configuration is more obviously wrong, in that it requires the user to use a unminified build of React. It's harder to fail in this manner because the burden of knowledge required to _just use the minified build_ is lower.

The configuration where you _think_ things are production-ready because you've run minification in webpack or Browserify but actually you aren't because you didn't set NODE_ENV – you can't get that via the CDN bundles.

I think React tab on Chrome Developer Tools enough to tells If we're in DEV Mode.

I think it's worth noting that there is some precedent for a framework injecting a DOM element into the page in dev mode:

http://symfony.com/blog/new-in-symfony-2-8-redesigned-web-debug-toolbar

Although as far as I can tell I don't think this is on by default.

Following the discussion above there seems to be a general aim to achieve a perfect solution which satisfies all the constraints but reliably stops everyone from running in dev mode when they shouldn't be. The OP stated that there would need to be a tradeoff between the potential experiences for developers and users, and I think this is very much the case.

To attempt to re-state the problem a tad:

• A non-zero number of React sites make it to production without development mode disabled
• We would like to reduce this number
• We don't want to annoy React developers
• We don't want to put off newcomers to React
• We don't want end-users of sites built in React to see cyptic developer warnings
• We don't want to break sites due to the presence of foreign DOM elements

Given these, I think a decent first step would be for React in dev mode to announce that it is in dev mode via a console.warn or console.info with instructions to make sure this is disabled for the production deployment.

Sure, this won't catch everyone but _it's a decent start_ which should reduce the number of people inadvertently shipping to production and doesn't close off any doors for future improvements.

Given these, I think a decent first step would be for React in dev mode to announce that it is in dev mode via a console.warn or console.info with instructions to make sure this is disabled for the production deployment.

It is not wrong for it to be in development mode though when you're... developing. What other heuristics could we use?

Also, given that nobody reads console on production, I wonder if we could throw inside a timeout so that it gets logged if you use crash reporting solutions.

It is not wrong for it to be in development mode though when you're... developing. What other heuristics could we use?

I think it should be similar to the current React DevTools notice

An informational message that reminds you you're in dev mode and that dev mode should be disabled for production sites. This (in theory) should make more developers aware that there is a distinction and some action needs to be taken to prepare for production use.

Like you say, almost no-one is going to see a console warning in actual production - and by that point it's a little bit late.

Sorry to sound like a stuck record, but console warnings don't appear to work. Eg https://code.gov.

Sorry to sound like a stuck record, but console warnings don't appear to work. Eg https://code.gov.

A single counter-instance shows that it's not infallible - but I don't think any approach will be.

If a console warning is able to increase awareness and reduce the number of people who mistakenly run dev mode when they shouldn't then this seems like a step in the right direction. Perfect is the enemy of good.

@jakearchibald

Yes, but if code.gov's build tool were set up with hooks here, then that _would_ have prevented the problem you're observing, at least in the context of React that uses build-time hooks for this. They are using webpack after all.

I am not saying that webpack should emit a build warning. I am saying that the right fix is that either webpack sets process.NODE_ENV for you, or that webpack just fails the build by default if you try to make a production build without appropriate production config.

Wanted to quickly respond to an earlier point from @addyosmani about DevTools "violations." We're prototyping showing stronger indications of certain errors in Chrome DevTools, but this work is still quite early, and I tend to agree with @jakearchibald that showing a warning (even if it's scarier than console.warn) isn't a good enough solution.

What about defaulting React to production mode and turning on development mode if and only if NODE_ENV == 'development' or hostname is localhost / 127.0.0.1? Most developers will get correct behavior out-of-the-box and there will always be a way to manually force development mode if you really need to.

Seems less than ideal to still be hitting that branch with what might be a fairly complicated conditional (since you'd need to not just fail on Node) all the time.

BTW, -p ("production" mode, which also enables minification with default settings) in webpack 2 sets NODE_ENV for users: https://webpack.js.org/guides/production-build/#node-environment-variable.

This seems quite sensible to me, and should just prevent this problem for almost everyone using webpack. Why the insistence on handling any of this at run time?

BTW, -p ("production" mode, which also enables minification with default settings) in webpack 2 sets NODE_ENV for users: https://webpack.js.org/guides/production-build/#node-environment-variable.

Yep. We're aware of this. @TheLarkInn from Webpack core could confirm for sure, but my understanding is that -p is not widely used in the Webpack community atm. The underlying issue here is also that if any solution is opt-in, similar to the current status quo with console.log warnings, we're unlikely to see real change for React users. We want to give folks a better change at shipping the 'fast' thing.

It's worth mentioning in passing that the lack of being able to easily detect DEV and PROD environments in Webpack (-p being insufficient) also caused us some pain over in https://github.com/webpack/webpack/issues/3216.

I am saying that the right fix is that either webpack sets process.NODE_ENV for you, or that webpack just fails the build by default if you try to make a production build without appropriate production config.

I'm up for us pursuing this but it would be a breaking change for Webpack from what I can tell. I personally feel like a runtime solution that involves a clear overlay message _only_ displayed using a few intelligent heuristics (localhost, DevTools open etc) would cover us adequately.

That said, as we keep circling back to the Webpack process.NODE_ENV item, I'd be curious if @sokra or @TheLarkInn had any opinions on this one.

My understanding differs from yours there – I believe that -p is the de facto way that most non-expert users of webpack set up production builds.

Even prominent packages use -p to generate production builds:
https://github.com/ReactTraining/react-router/blob/5e69b23a369b7dbcb9afc6cdca9bf2dcf07ad432/package.json#L23
https://github.com/react-bootstrap/react-bootstrap/blob/61be58cfdda5e428d8fb11d55bf743661bb3f0b1/tools/dist/build.js#L10

It's quite uncommon to directly configure the Uglify plugin in webpack, so without -p, people would be using un-minified builds, in which case they have bigger problems.

I personally feel like a runtime solution that involves a clear overlay message only displayed using a few intelligent heuristics (localhost, DevTools open etc) would cover us adequately.

I feel like this has been shot down multiple times (“It is unacceptable for a framework to inject things into the DOM”) without actually appreciating the _only_ scenario in which this would happen.

I am totally with y’all that having to cope with a permanent message and unexpected things in the DOM constantly during development is unacceptable. What we are suggesting here, though, is a message that gets displayed if and _only_ if DevMode gets deployed to production (enter heuristics!). An arbitrary number of checks and console messages can be built into tooling, CI and browser extensions to prevent that from happening.

But as a desperate, last resort failsafe I think a visible banner on screen is a good and appropriate solution.

displayed if and only if DevMode gets deployed to production (enter heuristics!)

So a developer will never see this message, deploy (perhaps accidentally) dev mode into production and suddenly they're seeing this new HTML being displayed on their application for all of their users to see?

That sounds more like a punishment to me. If you don't understand dev mode already and you deploy using this theoretical new version of React with the message then you're going to get a surprise and your users on the web application at the time also get to see it. I fail to see how this helps anyone but serve to embarrass the developer or company. Sure, maybe that'll get them to fix it, but that cost is too high in my opinion and lacking a bit of empathy.

But as a desperate, last resort failsafe I think a visible banner on screen is a good and appropriate solution.

The problem with this solution is that it is far too idealistic and when you're developing a framework you must focus on the reality that other companies may not have the greatest deployment policies or even the best QA (if any).

Yes, if someone deploys to dev mode in production they should be able to see it and change it quickly. Unfortunately, especially outside of the technology industry, this is simply not possible or not easy. The majority of the people commenting in here? Likely their companies have deployment processes that could cope just fine with this scenario. Google, Facebook, PlayStation, etc; all of these technology companies can handle this fine but this isn't representative of the majority of users that use React, right? (actually, do we have any statistics regarding the usage of React? Would be handy!)

Yes, yes these companies and government should change their deployment processes and policies etc etc. But the reality is this: most companies have crap deployment processes and crap to non-existent QA.

Let's take two scenarios in which I have personally experienced.

First, while working in the government, depending on branch and department, you likely have a single deployment every 3-6 months. These deployments roll up as much stuff as possible and if any piece of the entire deployment fails, everything may get rolled back. So we were using this software called OWF which, if you're unfamiliar, is like iSocial in that it displays multiple web applications in a single web application using iframes (gross, I know, but stay with me here). There was a manual configuration step in the deployment of several of our applications that failed which caused 404 and 500 errors to display in some of the iframes instead of the intended application.

Since developers typically do not have access to the system being deployed into it took many hours before we found out about any issues. At that point we had to get our boss to call someone else's boss to call their boss to tell them it didn't affect anything else so they wouldn't roll back the entire deployment. Then we had tons of paperwork and documentation to fill out before we could get anyone to redo some of the configuration several days later. Meanwhile the application sat, unable to function, during that entire period of time.

Second, when I worked in finance we had a deployment go out that inadvertently included a developer's name in place of an actual item's layout on the website (I believe he was testing something?). Anyway, it was noticed right away but in order to fix it we had to get an emergency change control through which took until much later that day. So their customers had to see this stupid banner for almost a full 8 hours before it was fixed.

My point being: there needs to be great care taken when injecting arbitrary elements into the DOM that the developer did not put there. Especially if we're talking about only displaying it in some scenarios then the first time someone sees it their going to figure out how to quickly disable it so they don't need to be bothered by it again.

@KrisSiegel

If you don't understand dev mode already and you deploy using this theoretical new version of React with the message then you're going to get a surprise and your users on the web application at the time also get to see it.

I was curious if your thoughts on the approach were any different if the message was only displayed while DevTools was open (i.e something that would have a low chance of being seen by production users that are not developers). Effectively an expansion of the current console.log strategy React already employs today.

I was curious if your thoughts on the approach were any different if the message was only displayed while DevTools was open (i.e something that would have a low chance of being seen by production users that are not developers). Effectively an expansion of the current console.log strategy React already employs today.

If you have dev tools open then you're probably seeing console.log messages so DOM changes seem like an unnecessary complexity to manage plus it's redundant. You could always make the React console messages larger / fancier. Maybe an ASCII React logo. Something to catch someone's attention should they happen to go in there.

Ultimately though I think someone would run into this, ask on Stackoverflow how to disable the warning, someone will post code showing them how to do it, then people will simply disable it if they run into it. Build tools are numerous and many folks that I've talked to in the past found them confusing or difficult (Babel 6's release was a "fun" time). You're going to run into a lot of people who simply never use them correctly.

At least that's my experience ¯\_(ツ)_/¯

Whew, finally caught up to the bottom of thread. Okay. I've been brainstorming this a little bit.

Webpack could force specifying NODE_ENV which React could then use to more easily avoid folks shipping DEV to PROD, but that would be a breaking change to Webpack. I'm talking to Sean now about how feasible something like that could be for Webpack 3. Keeping the React + Webpack stack beginner and perf friendly is something I know both camps care about.

This has felt like my favorite so far but I'm not 100% sold yet.

1. So could enforce that an ENV is passed in whenever anyone runs webpack. A helpful error message states that you must provide an env variable to run webpack.

However this provides a significant bounce point for users. Not everyone is writing for a prod or dev env or even know what an env is. I will raise an issue on webpack/webpack to get feedback on this, because my gut feeling is that not everyone will want this and whether I agree or not, we have to consider the pushback.

1. <something in-between 1 and 3 I haven't figured out yet>

2. The webpacky solution would be to create a standalone plugin that could hook into the compiler lifecycle, check if the code is being stripped, or if an ENV is not provided, and emit a friendly warning or error of your choice.

However I can imagine the response is "But users will never know how to do that etc." Thus CRA, thus this issue right now.

We could create a new resolver pattern that will check React's (or any fw that needs it) package.json for something like below:

"webpack": {
  "plugin": "ReactEnviornmentPlugin"
}

that would automatically apply to a users compiler configuration without them needing to know or care.

Again just really brainstorming.

@TheLarkInn I think the current behavior of -p in webpack 2 is sufficient, no? The only failure case is if someone sets up UglifyJsPlugin themselves and forgets to do DefinePlugin, but that seems like a far less likely case.

@taion Yes/No

-p only applies production "treatments" to your code, however we do not make any assumptions about and/nor have any knowledge of what NODE_ENV is set to. This is what brings upon the need for people to use DefinePlugin().

But I do think it is the closest "_reasonable_" area to _guess_ or _imply_ that the user is running their code in a production ENV. That would be the one area that we would want make sure the community and team is okay with.

@TheLarkInn I believe this changed in v2: https://webpack.js.org/guides/production-build/#node-environment-variable

Ah sorry that's right I'm mistaken. It however it's not used frequently because people want more fine grained control over what they optimize. (Like @addyosmani mentioned)

Is that really so common? When I was getting started with webpack, -p clearly seemed like the way to go. Like I referenced above, even libraries with plenty of reason to apply further tweaks still use -p.

We could create a new resolver pattern that will check React's (or any fw that needs it) package.json for something like below:

"webpack": {
"plugin": "ReactEnviornmentPlugin"
}
that would automatically apply to a users compiler configuration without them needing to know or care.

@TheLarkInn if I'm reading this correctly, to trigger the resolver pattern an app's package.json would need to manually specify the ReactEnvironmentPlugin, right? Or am I misunderstanding the proposal? :)

I could imagine some resolution magic in Webpack that detects a project is using React and does the right environment switching for them, but that sounds like a tight coupling of framework-specific optimisation to a bundler and might not be as desirable.

Less that it would detect react, and more that it would detect a js modules description fields include a webpack field with a plugin. But you are right, it is very tightly coupled and not really my favorite idea either.

I don't think this really gives you any guarantees unless webpack has a concept of "production" mode to figure out how to configure React – and this seems redundant given that, as discussed above, -p already does the right thing, and is what users will generally reach for when making a minified production build with webpack anyway.

We’ve talked about this a bit more and I think there is a reasonable solution.

We’ve long considered enabling a “warning box” for React warnings in development. You can see a demo here (PR: https://github.com/facebook/react/pull/7360). It only shows up when you have warnings but they are very common during development (and should always be fixed), so presumably anyone who spent more than five minutes developing an app will see the dialog and be aware that it exists.

After this change, it will be harder to be unaware of the development mode. You’ll likely search for “how to remove the warning dialog” and learn about building for production. If you don’t, you’re likely to get some warnings deployed at some point, and your users will see them. I think that in this case people won’t blame React per se because we don’t just show the box to be obnoxious—we just do what the development mode is supposed to.

(By the way, we’ve been using a similar warning box in development at Facebook for a long time so it corresponds to how we intend React to be used.)

I am really happy to see that proposal, @gaearon! It’s everything I dreamed it to be ;)

Just as an side: Maybe it’s worth considering having a link directly in the box to not require the developers to google for how to get rid of it.

Yea, good point. We'll add something.

@gaearon I find that solution highly obnoxious; I would never want warnings to invade the DOM even during development. That serves zero purpose for the common developer and would likely be disabled in its entirely by most. The developer tools display warnings for a reason, they don't need to be invented.

I also find it troubling that DOM solutions keep cropping up with zero rebuttals to any of my prior arguments against it. If my points are to be ignored then fine, this isn't my repository so that's fair enough, but it's disheartening to see the same argument come up, people post against it, people seem for the points as there is never an argument against them, then they just come right back up. Rinse, repeat.

While I agree about this being true about most warnings, React warnings specifically point out the bugs in your code. They are not just suggestions.

The dialog is easy to dismiss and the individual warnings are easy to snooze (in case you don't care about them for a while) but they need to be fixed.

For comparison, this is how the dialog looks in the Facebook codebase:

Thousands of engineers don’t have a problem with it and are more productive thanks to it, so we think it’s a reasonable default. To be clear, the open source version will be less shouting:

If you have suggestions about style tweaks please feel free to comment on https://github.com/facebook/react/pull/7360.

Adding onto what Dan said, I'm building on top of the #7360 to hook into our recently-added error logger flow. I'm currently trying out a couple of styles of toast notifications that are a little less intrusive. I'll post some screenshots and/or a Plnkr soon for feedback.

Would these warnings include the "minified dev code" warning? That'd solve a lot of things quite neatly if so.

I don't see why it couldn't also be used for that purpose.

@gaearon

While I agree about this being true about most warnings, React warnings specifically point out the bugs in your code. They are not just suggestions.

Those should be errors or exceptions IMO. Why are they not? Exceptions force things to be corrected but a dismissible warning does not.

Thousands of engineers don’t have a problem with it and are more productive thanks to it, so we think it’s a reasonable default.

I mentioned this in a prior point but I would guess those engineers are likely better than a good 90% of people who will use the open source version. I find it the opposite of a reasonable default. There is a reason development tools have warnings; reinventing them doesn't make sense to me. It'll get disabled and never seen again.

This just looks like React is trying to do too much IMO.

When I did government contracting we had a common library all front ends had to use. It would take errors in the console and display them as a toast pop up. No only did it get deployed to production multiple times by multiple teams but many developers saw it once then asked how to permanently disabled it. I see this as more of the same.

We’ve long considered enabling a “warning box” for React warnings in development. You can see a demo here (PR: #7360). It only shows up when you have warnings but they are very common during development (and should always be fixed), so presumably anyone who spent more than five minutes developing an app will see the dialog and be aware that it exists.

I really like #7360, @gaearon. It's heartening to hear support for highlighting the need to switch to PROD for deployments in the new warning box. It's nice and visual.

Adding onto what Dan said, I'm building on top of the #7360 to hook into our recently-added error logger flow. I'm currently trying out a couple of styles of toast notifications that are a little less intrusive. I'll post some screenshots and/or a Plnkr soon for feedback.

@bvaughn Looking forward to seeing more of your iterations :)

For folks who feel the warning box approach may be too intrusive, other libraries (e.g VueJS) already display DOM overlays during your dev/iteration workflow to encourage bug-fixing or slow-paths:

My own experience has been that while it's a minor inconvenience, these messages are more obvious than what you might see in the console. I feel Dan's right that it'll at least place more emphasis on dev mode not being something you should deploy to prod and will hopefully lead to more sites shipping "faster mode" to their end users.

After this change, it will be harder to be unaware of the development mode. You’ll likely search for “how to remove the warning dialog” and learn about building for production. If you don’t, you’re likely to get some warnings deployed at some point, and your users will see them. I think that in this case people won’t blame React per se because we don’t just show the box to be obnoxious—we just do what the development mode is supposed to.

Those should be errors or exceptions IMO. Why are they not? Exceptions force things to be corrected but a dismissible warning does not.

While they should be fixed, I might have more urgent matters at hand. For example do I often prototype/mock up UIs and while doing that I write quick and usually sub-par code which React can warn about. While I want to fix those warnings, I don't really care until I know that I wont throw away all the code in the next hour at least. Forcing people to fix them instantly will drastically slow down experimental development.

For folks who feel the warning box approach may be too intrusive, other libraries (e.g VueJS) already display DOM overlays during your dev/iteration workflow to encourage bug-fixing or slow-paths:

screen shot 2017-01-24 at 10 57 11 am

Are you sure that's from Vue itself? It looks a lot like webpack build errors displayed with the error overlay from webpack-hot-middleware. If this is the case, it's subtly different because it's dev-time build tooling adding the overlay rather than a general-purpose frontend framework.

In general I'm in favour of the warning overlay, but I think it should contain explanatory text on it that says what it is, why it's there, and that it can & should be disabled as part of turning off dev mode. Behind an expando if that's a bit long - but it seems like as good a place as any to get the message across.

I dread updates like 15.2.0 with an overlay. minor bump and suddenly you have literally 100s of warnings about props being passed to DOM nodes. errors maybe, but I don't think depreciation warnings belong in such an intrusive space

errors maybe, but I don't think depreciation warnings belong in such an intrusive space

I don't know if this was very clearly communicated prior, but the idea regarding yellow-box warnings (#7360) was not to show _all_ warnings (deprecation or other). Rather, certain warnings that the team deemed to be _particularly important_ would be highlighted this way. The rest would presumably remain in the console.

At least that's my take-away from the conversation Tom and I had about this feature a week or two ago.

The prop warning in 15.2 was also a mistake IMO and not indicative of our normal M.O. We'd like to have a way to control warning levels by minor versions to avoid that.

The main reason our team does not use the production build is because we can't run JS unit tests, since the test utils are not included.

First, another round of thanks to the React team (@sebmarkbage, @gaearon, @tomocchino and others) for discussing this issue with us and being so open to talking to us about performance & mobile at BlinkOn and other syncs this quarter.

Status check

Per @aweary in https://github.com/facebook/react/pull/7360, the Yellow Box solution to this particular problem has been put on hold until React’s high-prio V16 work gets completed but should still be happening. https://github.com/facebook/fbjs/pull/165 needs to land and be implemented in Fiber. A good public API for exposing hooks also needs to be crafted. Will be keeping my fingers 🤞

This problem appears to still be prevalent

Quite a few of the production apps that have come across my desk are still shipping DEV mode to production. We can see the When deploying React apps to production debug string in their builds here:

https://cdnjs.cloudflare.com/ajax/libs/react/15.3.1/react.js (tombraider.com)
https://shared.reliclink.com/dlls/vendor-f3e016f6037eb107ffc0.live-shared.min.js (dawnofwar.com)
https://d1xx3pvec9nqb7.cloudfront.net/media/js/thread.af65c1a02d15.js (thread.com)
http://www.sothebys.com/etc/designs/redesigns/sothebys/redesignlibs.min.js (sothebys.com)

I'm still of the view that a pre-Yellow Box move to logging the DEV mode warning to console for the above might have some impact. Sebastian's suggestion of throwing a console error so crash reporting might pick these up was also something I felt was worth consideration.

What else can we do to move the needle here?

Better advocacy? I'm happy to commit to continuing to advocate for folks not shipping DEV mode to production, but do want to see if we can land the official solution post V16 :)

In the short-term, it looks like create-react-appis in a good place to help new projects avoid this problem.

Improvements to installation docs

For everyone else, would there be support for https://facebook.github.io/react/docs/installation.html including a clear, visible callout under the Installing React heading reminding folks to be mindful of DEV mode in production?

As a user, I don't feel there's great incentive for me to read https://facebook.github.io/react/docs/installation.html#development-and-production-versions on first glance otherwise.

Thoughts?

The main reason our team does not use the production build is because we can't run JS unit tests, since the test utils are not included.

I’m confused about this. Are you running tests on production website? If not, what prevents you from using production build on the production website, and development build in development?

For everyone else, would there be support for https://facebook.github.io/react/docs/installation.html including a clear, visible callout under the Installing React heading reminding folks to be mindful of DEV mode in production?

Sure. Want to send a PR?

Sure. Want to send a PR?

More than happy to.

Maybe a word about benchmarks would be nice too to help educating those who compare perfs with react in dev mode ?

Makes me think the react devtools extension could be leveraged to display a notification or something obvious when opening a page using react in dev mode maybe ?

I like this idea! I put together a set of proposed icons for the devtools (see facebook/react-devtools/pull/652).

We need to decide how to detect dev vs prod React in a way that's backwards and future safe, but I've added it to the Monday meeting agenda.

We’ve done some reasonable steps to address this problem:

• React DevTools (with ~700K users) now displays a distinctive red icon for development builds. This helps people learn about the difference between versions early. It also creates some peer pressure, as developers notice this on sites they visit, and report to the people working on them. We’ve seen a few major sites fix the issue within days of rolling this out.

• The notice in React DevTools links to our website where we published instructions to create the production build for all major bundlers. We also made it more prominent on the installation page.

• Create React App continued to gain popularity. It teaches this distinction early with separate commands. It also displays a permanent notice about development mode in the terminal.

• React 16 Beta 1 (and further releases) ship with react.development.js and react.production.min.js as filenames to make it clear that non-minified build should not be used in production.

I think in the future we might explore more ways to solve this problem, but for now I feel like we can move ahead without more drastic measures, and see if it helps. Thanks to everyone for the discussion.