Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove React DevTools Download console log on install #3877

Closed
RichardLitt opened this issue May 14, 2015 · 55 comments
Closed

Remove React DevTools Download console log on install #3877

RichardLitt opened this issue May 14, 2015 · 55 comments

Comments

@RichardLitt
Copy link
Contributor

RichardLitt commented May 14, 2015

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 #3877 (comment).

@RichardLitt
Copy link
Contributor Author

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:

screen shot 2015-05-14 at 3 50 58 pm

@zpao
Copy link
Member

zpao commented May 16, 2015

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 added a commit to BeagleLab/beagle that referenced this issue May 18, 2015
This removes the React Devtools message which always shows up. It also removes the Devtools functionality. See hughsk/envify#27 and facebook/react#3877.
@RichardLitt
Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Collaborator

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

@sebmarkbage
Copy link
Collaborator

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

@RichardLitt
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link

ghost commented Sep 20, 2015

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
Copy link
Collaborator

gaearon commented Sep 20, 2015

@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
Copy link

ghost commented Sep 20, 2015

@gaearon Thank you for the tip. Works fine!

@sophiebits
Copy link
Collaborator

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

@CacheControl
Copy link

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
Copy link

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
Copy link

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
Copy link
Collaborator

@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
Copy link

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

@liddellj
Copy link

liddellj commented Feb 3, 2016

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
Copy link

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
Copy link

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

@sophiebits
Copy link
Collaborator

@mvasilkov What browser do you use?

@mvasilkov
Copy link

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
Copy link
Collaborator

We could also add react-devtools to the Opera catalog (facebook/react-devtools#178).

@Sieabah
Copy link

Sieabah commented Aug 11, 2017

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
Copy link

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
Copy link
Collaborator

gaearon commented Oct 2, 2017

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
Copy link

Sieabah commented Oct 2, 2017

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

@gaearon
Copy link
Collaborator

gaearon commented Oct 2, 2017

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
Copy link

Sieabah commented Oct 2, 2017

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
Copy link

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

@gaearon
Copy link
Collaborator

gaearon commented Oct 3, 2017

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
Copy link
Collaborator

gaearon commented Oct 3, 2017

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
Copy link

Sieabah commented Oct 3, 2017

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
Copy link

@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
Copy link
Collaborator

gaearon commented Oct 3, 2017

@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
Copy link

Sieabah commented Oct 3, 2017

@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
Copy link
Collaborator

@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
Copy link

Sieabah commented Oct 4, 2017

@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
Copy link
Collaborator

gaearon commented Oct 4, 2017

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

@Sieabah
Copy link

Sieabah commented Oct 4, 2017

@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
Copy link
Collaborator

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
Copy link
Collaborator

gaearon commented Oct 4, 2017

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
Copy link

Sieabah commented Oct 5, 2017

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
Copy link

luisrudge commented Oct 6, 2017

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
Copy link

Sieabah commented Oct 11, 2017

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() {},
};

@gaearon
Copy link
Collaborator

gaearon commented Oct 28, 2017

The easiest way to completely disable this is to do something like

    new webpack.DefinePlugin({
      __REACT_DEVTOOLS_GLOBAL_HOOK__: '({})',
    }),

in your webpack config. This will disable both the warning and the DevTools integration.

If you don't use webpack, there are equivalents: envify in Browserify and replace plugin for Rollup. All of them can do simple string replacement like this. If you don't use a bundler at all, and consume React from a single file, you can set up a build step that performs a similar string replacement over the bundle.

I’m sorry if this is still frustrating, but I believe this is sufficient to address the problem. A build-time flag makes more sense to me than a runtime one, and this is pretty what a build time flag would look like anyway.

Any dependencies you use that work on top of React may bundle React in production mode with them. Then you wouldn’t see the message in the first place. And if you use a bundler, the approach I suggested above should work.

So I’m closing this.

@gaearon gaearon closed this as completed Oct 28, 2017
@aaronjensen
Copy link

aaronjensen commented Nov 3, 2017

@gaearon as of react 16, your suggestion replaces the info message with a warning:

if (!hook.supportsFiber) {
if (__DEV__) {
warning(
false,
'The installed version of React DevTools is too old and will not work ' +
'with the current version of React. Please update React DevTools. ' +
'https://fb.me/react-devtools',
);
}
// DevTools exists, even though it doesn't support Fiber.
return true;
}

I believe one would need to do what was suggested in #3877 (comment)

@gaearon
Copy link
Collaborator

gaearon commented Nov 4, 2017

Oh, I see. Somehow missed that. Let's address this with #11448.

@gaearon
Copy link
Collaborator

gaearon commented Nov 4, 2017

Okay, now that #11448 is merged, 16.1.0 will include the fix that lets you specify:

   new webpack.DefinePlugin({
      '__REACT_DEVTOOLS_GLOBAL_HOOK__': '({ isDisabled: true })'
    }),

(or equivalent with your bundler), and the warning will be silenced.

@gaearon
Copy link
Collaborator

gaearon commented Nov 4, 2017

Going to lock this so the answer above doesn't get lost.

If you still have this issue after upgrading to 16.1.0 (to be released in a few days) please file a new issue.

@facebook facebook locked and limited conversation to collaborators Nov 4, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests