Remove React DevTools Download console log on install

[RichardLitt]

I have React DevTools downloaded and enabled as a Chrome extension, version 0.13.1. I am using the react npm package, version 0.12.2, in a Chrome extension that is browserified.

Every time I open my console, the console log: "Download the React DevTools for a better development experience: http://fb.me/react-devtools" is there.

What can I do to remove this?

Update from maintainers: see solution in https://github.com/facebook/react/issues/3877#issuecomment-341857218.

[RichardLitt]

I don't see a React tab in my Chrome Dev tools, also, so I'm not quite sure how to access the dev tools at all to be honest. Here is what I see in my Chrome settings:

[zpao]

If you browserify with NODE_ENV=production, then you'll get the prod version, which doesn't have that message. You probably want to do that for your extension users anyway.

As to actually debugging, I'm not sure the best way about this. The DevTools are expecting to be inspecting the browser window, which is why they aren't playing nicely together (devtools set a global on the browser window, but React is looking for it in the context of it's execution environment, which isn't the browser window).

We might have to just close this but a quick cc of @sebmarkbage to see if he has any other comments.

[RichardLitt]

Alright, I run it in production mode now. But now I can't use the React Developer Tools at all. So... I guess the extension just doesn't work at all for cases like mine?

[sebmarkbage]

What do you mean? You can't use the React Developer Tools to debug the extension? What kind of extension is it? Did you use the chrome://inspect tools to open the extension?

It may not be possible to use React DevTools to debug extensions because of how we insert a global flag into pages to find the React instance.

[sebmarkbage]

I think it should work if you have global React or a global require that is able to require('react') from global scope.

[sebmarkbage]

Btw, any reason you're stuck at React 0.12.2 and not upgraded to 0.13 yet?

[RichardLitt]

Maybe I'm doing something wrong: What I mean is that I don't see the 'React' nav item in the Console. I'm not sure I ever have, come to think of it. I certainly don't know, and didn't when I got that warning I mentioned above. I'm not sure what kind of extension types there are; mine is a chrome extension that uses a browser_action to inject an iFrame or to reload a PDF in a URL inside a PDF.js environment. Yes, I used chrome://inspect - no dice.

I have a global require('react'), I believe.

I've got some issues in some other dependencies that mean I'm just using npm-shrinkwrap, and haven't updated a few modules. No other reason besides that. I could update it now.

[RichardLitt]

I should be clearer about this: I've never gotten React Developer Tools to work that I can recall, and I keep getting a warning about using it which I wanted to turn off, which is why I made this issue.

[ghost]

Is there any progress on this?

I'm using webpack, es6, babel, React 0.13.3 with NODE_ENV=production set and still see the message in console.

react-devtools not installed since it is production mode

[gaearon]

@appshore Just using NODE_ENV is not enough during compilation; you need to actually define it in your code. One way to do this is to use DefinePlugin in Webpack.

  plugins: [
    new webpack.DefinePlugin({
      'process.env': {
        'NODE_ENV': JSON.stringify(process.env.NODE_ENV)
      }
    })
  ]

[ghost]

@gaearon Thank you for the tip. Works fine!

[sophiebits]

(Please note that you should not use NODE_ENV=production during development as it silences many helpful warnings.)

[CacheControl]

If you set window.__REACT_DEVTOOLS_GLOBAL_HOOK__ = {}, it will also silence the warning. This seems preferable to using NODE_ENV=production, which may have other consequences.

[alexoviedo999]

I was able to make the extension work by requiring react in my gulpfile. I'm sure it would work the same in the webpack file: var React = require('react');

[silvenon]

This was bugging me when I was testing, because I wanted my NODE_ENV to be test, not production. It was throwing because I didn't have a DOM, and Node's console doesn't have a debug method. global.__REACT_DEVTOOLS_GLOBAL_HOOK__ = {} saved me, thanks @CacheControl.

I thought it was a react-dom thing, which I wasn't using. I wonder how it got required…

[sophiebits]

@silvenon If you were using node, wouldn't the user-agent check prevent the message? We can add a check for console.debug if that would be helpful.

[silvenon]

@spicyj oh, right, I faked the user agent because Radium wanted a real one, that's why React picked it up. My bad :sweat:

[liddellj]

I would also like to see a nicer way of suppressing this message. I'm using zombiejs to execute E2E tests against a React app, and unless suppressed using the global.__REACT_DEVTOOLS_GLOBAL_HOOK__ = {} hack above, this message appears in the middle of my mocha output, spoiling the party.

[rossipedia]

Same here. I use React for a small part of a larger project, and many of the other devs don't want that message crowding their console on our Dev tier. A standard way of disabling this message that doesn't involve altering the source code would be highly preferable.

[mvasilkov]

I don't even use the dreaded Chrome browser, why am I seeing this spammy advertising in my console? Please remove, kthxbai.

[sophiebits]

@mvasilkov What browser do you use?

[mvasilkov]

Opera. It doesn't support installing Chrome add-ons out of the box.

And yes, I know how to make it work, but that's not the point — why in the nine hells do I even see ads in my developer console, while working on my project? Do we seriously need an AdBlock for the JS console now, to silence this type of incredibly intrusive advertising, because Facebook?

Sorry guys, I love React, but putting permanent ads in there was just not very good of an idea, was it.

(BTW tomorrow is the React Next 2016, let's beer.)

[sophiebits]

We could also add react-devtools to the Opera catalog (https://github.com/facebook/react-devtools/issues/178).

[Sieabah]

This somehow permeated from auth0-lock and into my Angular application. Installing the dev tool for a platform I don't even use isn't what I want to do.

[mvasilkov]

A year has passed since my last message, and Facebook is still pushing irrelevant ads into my dev console. Install our MSN toolbar^W^W browser extension!

Here's an idea, put a YouTube video there, with auto-play. Stay classy.

[gaearon]

@mvasilkov

Why is it irrelevant to you? I believe it is possible to install React DevTools into Opera now—at least that's what I've heard. We're pushing it hard because developing real apps without DevTools is pretty complex, and the importance of getting newcomers to try it is larger than the annoyance it brings to the minority of users who don't need it.

If it's really a browser thing (e.g. it doesn't work on Opera after all) we're happy to add a check that disables it on Opera specifically. Just let us know.

[rossipedia]

@gaearon I still don't see the problem with adding some sort of opt-in method that can disable this message at runtime. there definitely are legitimate situations where that message might not be ideal, even in a dev environment.

[Sieabah]

@gaearon @rossipedia Like for example when you're in an Angular application.

[gaearon]

I still don't see the problem with adding some sort of opt-in method that can disable this message at runtime.

There is a method already, even though it is hacky. It is documented above: https://github.com/facebook/react/issues/3877#issuecomment-150632468. I think that if you don’t want the warning to show up in your app, you can always use this.

[Sieabah]

@gaearon Probably is the most hacky non solution offered, especially when that hook changes since it's a double underscore variable.

EDIT: This is also a dangerous approach as when you have a submodule who chooses to opt-out and it opts out for everything above and below it.

[gaearon]

This is also a dangerous approach as when you have a submodule who chooses to opt-out and it opts out for everything above and below it.

Don’t you have the same problem if we added an official API for it? In fact that’s the primary reason any API seems unfortunate here.

[Sieabah]

@gaearon If it's opt-in, it's not

[gaearon]

Making it opt-in defeats the purpose: people who we want to reach won't know to opt in.

Please try to see it not just as an annoyance affecting you, but in the broader context of why we think it is useful, and how it benefits the ecosystem. If there is a solution, it should solve the original problem too.

[Sieabah]

I'm not a react developer, but you should be able to bootstrap the react app with whatever settings you want. Meaning someone like auth0 could disable it within their own react instance but for other components it would be enabled. The current solution where you hook into a global variable is really the big problem here.

If every module had this type of mentality it would be quickly be called console spam.

[rossipedia]

The global hook is 👍 I absolutely understand and appreciate the value, which is why I prefer opt-out instead.

[gaearon]

Meaning someone like auth0 could disable it within their own react instance but for other components it would be enabled

I don't understand you. If auth0 somehow "opted out" it would have effect both on React and non-React consumers. The only way it could possibly help you is if the behavior was global. So you are in fact advocating the global flag, which is pretty much what setting that global gives you. I agree it's hacky though and I'm open to other proposals.

[gaearon]

And to clarify, auth0 doesn't have its own React instance unless it bundles the whole React with it. npm will rightfully deduplicate React so that people whose apps are already using React don't end up with two Reacts in a bundle.

[Sieabah]

Like I said, I'm not a react developer so I don't know the workflow. In Angular you can bootstrap multiple applications and they're absolutely separate. If the flag to leave this log was in the react instance a developer(Auth0) could toggle it for their own released widget. Currently with the global variable they are not able to do that.

What I mean by bundled react is the instantiated react application.

[mvasilkov]

@gaearon whoa I'm talking to Dan Abramov! Huge fan.

As to why repetitive advertising of some browser toolbar is irrelevant:

• The JS console is a developer tool I use. This is not by accident: I actively want to use it for stuff.
• The thing you're promoting is not a developer tool I want or need. This is also not accidental, as I made an informed decision that I don't want it.
• Could we please allow developers a choice? Or an ad-free development environment? Pretty please?

Imagine that other developers, seeing Facebook as a trendsetter, start promoting their stuff in the JS console too. Not necessarily browser extensions: referral links to books on Amazon are also a thing. Or YouTube series with some lessons for beginners. Wouldn't that be awesome:

Download the React DevTools with MSN Toolbar for a better development experience!
The funky progress bar is about the coolest thing with npm! Click here to download.
Our new book on jQuery, "Write it like it's 1998", is out now! Buy on Amazon
Check out new and trending sans-serif fonts available on Google Fonts!
Failed to load resource: net::ERR_BLOCKED_BY_CLIENT
> console.log("let's die together in hell")

[gaearon]

@Sieabah

I’m not sure how these concepts from Angular translate to React. If you have specific API suggestions please let me know.

@mvasilkov

I agree with you in theory. In practice the need to educate our users about DevTools is higher than the downsides of noise for few users (note that this is a two year old issue and only a dozen people complained).

There is no need to invoke the “slippery slope” here. The message has been there for years, and nothing that you described happened.

Again, I’m open to solving it somehow, and I’m open to proposals. But if your proposal is just “turn it off” then it shows you’re not interested in solving the problem holistically, including finding another way to achieve the initial goal (educating beginners about DevTools).

[Sieabah]

@gaearon Like I said, there is a disconnect between my knowledge of how Angular does it's thing vs how React works. To put it simply for Angular to run it must be bootstrapped, essentially it's how Angular knows when to start and with what module, that module is instantiated and has it's own configuration. An example here with the module definition.

There may not be something similar in React but it would be at the module instantiation (the actual react app) which could pull in the dev-tools module (which logs that you don't have dev-tools installed) and disable the logging for just that instantiated application. This at least offers the opt-out method which is preferred.

If enabled it would look for the window.__REACT_DEVTOOLS_GLOBAL_HOOK__ variable, and if undefined it will log.

[sophiebits]

@Sieabah Do you know if that library is using React to render things or only loading React without rendering anything? If it's the latter, we could change React to do this log on the first render (instead of on app startup) but if it's the former that won't help.

[Sieabah]

@sophiebits It's essentially a widget that offers a login prompt.

The culprit is line 73 of ReactDOM.js, which looking into it finds its environment from ExecutionEnvironment. (fbjs/lib/ExecutionEnvironment)

If the application can push something into the ExecutionEnvironment or something equivalent saying to disable logging in this environment for this instance then I believe that's a fair tradeoff. The logs are presented to people who react as their app and devs who publish their widgets can opt-out of the log.

[gaearon]

If the widget is broken/buggy, would it not be valuable for Auth0 users to know the tool for debugging it?

[Sieabah]

@gaearon Still would be useful to have the developer choose to opt-out of the logging. If I narrowed my bug down to auth0 I would be going on their github and creating an issue. From there I'd learn what I'd need to configure to debug their widget.

[sophiebits]

I think if auth0 doesn't expect you to care that it is built in React, it should probably use the production React build which doesn't have this warning. I wonder if it is currently always using the dev build or if it switches depending on if your app is in prod mode.

[gaearon]

This sounds like a good solution to me too. Autho0 could even offer two options: one for React users (which relies on your app's React version), and one for non-React users (which includes bundled production React). This makes sense because these two audiences might want different APIs (React component vs imperative API) and because non-React consumers might have a build system that doesn't know how to switch between development and production versions of React.

[Sieabah]

I just want to pass in at startup a config option on whether or not debug/dev mode is enabled. If it can be reliably compiled ahead of time that's also good.

The issue currently is I want my app to be in dev mode but using a production widget so to rely on NODE_ENV (as it does now) doesn't correctly handle this case.

[luisrudge]

Hi. I'm from Auth0. Our widget uses the prod version of react in the CDN. But if you add our widget via npm, then users are required to bundle their applications with a module bundler to use it in prod mode (set process.env.NODE_ENV to "production"). Does that make sense?

[Sieabah]

For those now getting the error with:

Warning: The installed version of React DevTools is too old and will not work with the current version of React. Please update React DevTools.

window.__REACT_DEVTOOLS_GLOBAL_HOOK__ = {}

now need to put this instead.

window.__REACT_DEVTOOLS_GLOBAL_HOOK__ = {
    supportsFiber: true,
    inject: function() {},
    onCommitFiberRoot: function() {},
    onCommitFiberUnmount: function() {},
};