Console log shows the wrong destination file

[QJerryxjh]

in my browser console, log info go wrong, it should show real console.log file and correct line info, but now it always show "react_devtools_backend.js: 4049", link to source code show warning:
"Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details.

• Move data fetching code or side effects to componentDidUpdate.
• If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
• Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run npx react-codemod rename-unsafe-lifecycles in your project source folder.
  Please update the following components: %s"
  when i disable react developer tools, it goes correctly. but it goes wrong in 4.18.0 react developer tools. and my colleagues' chrome with react developer tools 4.17.0 is right

Note from maintainers: #22257 (comment) is a workaround until this is fixed in React DevTools

[gaearon]

Can you try clicking the arrow to the left of the message? It should expand the full stack which gives you precise location of every frame including the one you’re looking for.

Also please show the screenshot of your DevTools settings.

[QJerryxjh]

@

[QJerryxjh]

@gaearon sry, it looks like i have a wrong devtools setting,thank you for you help

[mattywong]

Hey @gaearon, we seem to also be getting this issue on regular console logs (sourcemaps mapping to react_devtools_backend.js:4049). When the react devtools extension is disabled, sourcemaps show correctly. Webpack devtool is set to 'eval-source-map'. This seems to have happened quite recently as I don't recall seeing this before. Let me know if you need me to provide any other info.

Left: incognito with react devtools disabled, Right: with react devtools enabled

[gaearon]

Not sure if anything changed here but reopening just in case.

[keul]

I can confirm: it seems that every console.something is captured by the extension.

[bvaughn]

Chiming in here to confirm that this reported behavior is intentional– although I understand the confusion or annoyance. 😦

The "problem"

As of the version 18 release, DevTools always overrides the native console to either dim or suppress StrictMode double logging. (Before it only did it if you enabled a feature like component stacks.) DevTools also now overrides console.log (for double logging) so it's more noticeable. (Before it only overrode console.error and console.warn– to add component stacks.)

The major unfortunate drawback of this overriding is that it changes the location shown by the browser's console as reported in this issue. I requested better tooling support from browsers a couple of years ago because of this, but there hasn't been any action unfortunately: whatwg/console#163

There is a related tc39 proposal but I don't think it has made any progress since then.

A possible solution

One possible change we could look into making on the DevTools side to improve this default experience is to only patch console methods during StrictMode double render. (Even if other features like component stacks are enabled, we wouldn't have to override the console.log method.)

Right now the way this works is that DevTools eagerly patches the console APIs, and asks React to check if StrictMode is active to know if it should also dim or suppress. Perhaps we could change this so that React called a DevTools API instead to notify when double rendering started, and then DevTools could only patch console.log during a double render.

cc @lunaruan

[mattywong]

Perhaps a setting could be added to devtools to opt in to this new behaviour (or opt out)? Atleast till theres a way to fix both? Tbh i had no idea of the double logging issue or maybe had just never noticed it, and I would assume others would be in the same boat. The source map line change however is definitely noticeable and arguably a much more annoying issue (imo)

[gaearon]

Yes, we understand why the issue is annoying and will look into some way to resolve it.