-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
console.log commands are not shown their code line locations #26788
Comments
Can you run If you believe this information is irrelevant to the reported issue, you may write `[skip envinfo]` alongside an explanation in your Environment: section.
|
@motiz88, does this look familiar to any recent changes? Maybe something like framesToPop on console.log? |
This is probably due to the way we wrap console methods to add React component stacks. I'm not sure whether Chrome exposes a way to manipulate the call site attribution for logs. cc @bvaughn |
I'm not sure why and how it's happening but it would be more better to work like other version. |
I'm getting the same result in my console with the newer versions of RN. |
@motiz88 It does not, although I did open a discussion issue about this type of thing: It got a little attention initially but seems to have fizzled 😞
@ezranbayantemur @motiz88 This is a React DevTools v4 feature, so it would be expected to impact RN v61+. You should be able to disable it in the general settings.
|
I'm also experiencing this after upgrading to React Native 0.61.2. Worked fine in 0.60.x |
To be clear, this is 100% expected to happen for v61+ and not for v60 (or earlier) because v61 embeds the new backend from I also made a judgement call for the override to be on by default (so it's opt-out rather than opt-in) because (1) people might not be running the DevTools frontend at all and (2) even if they were, there's an initialization race during which any logged errors would not get the appended callstack. This decision is somewhat controversial. If folks feel that I made the wrong decision by defaulting on, we can talk about it. |
Thanks @bvaughn - for those of us on v61+ now, what's the recommended toolset to continue debugging to see line numbers? I'm willing to switch tools if it means I can see the line numbers again. |
See my comment right above where I copied instructions for disabling it? |
When I tried to start react-devtools v4, it said: Is this documented anywhere for me to read more and understand the issue rather than me continue to ask questions? |
Does not sound like you are running v61 of React Native if you saw that message. The v4 frontend can only connect and work with the v4 backend, and vice versa. |
Hm, I followed the upgrade guide and checked every change in every file, it's definitely on that version as I have fast refresh as well.
|
I was tracking logs on Google Chrome Debugger, not React Devtools, so there is no way to disable such as you mention it. But anyway, like @acoutts said when I try to devtools I got incompatible errors. |
I also use Chrome Debugger tools, It feels simpler... if this decision can be discussed, count my vote for allowing to see logs like before without having to install React DevTools. |
Can we default it to see logs as they were before if React Devtools is not installed? |
My takeaway from this is that the current default is probably not working out very well for folks, so I'll change it (off instead of on). Sorry for the inconvenience. |
Thanks @bvaughn. I think most of the confusion comes from most people not using react devtools but just using Chrome (the thing that opens by default when you enable debugging). |
Follow up clarification question for @ezranbayantemur @ledzep9012 etc: Why was the "before" behavior of showing |
@bvaughn I was referring to |
Gotcha. I misunderstood the screenshots. DevTools overrides However, this override is deferred until the first time a component is actually inspected (which would never happen if you weren't using the DevTools UI). It's also unpatched as soon as we're done inspecting. (See the source code here.) So I'm now unsure of how the originally reported issue was being triggered. Are we actually seeing |
I think there’s a misunderstanding. Could it be that console.logs are being eaten by the thing that sends them to Metro? So then it wouldn’t be React DevTools-related at all. In that case ideally the fix would be to somehow detect if we’re in a “rich console” environment like Chrome or not. When we are, don’t hijack console to send logs to Metro. A possible way to detect that could be to check whether console methods are native or RN polyfill. Maybe by toString-ing them. Or by checking for some Chrome specific property on console. Need to make sure the fix doesn’t give a false positive for Hermes. |
Yes. I assumed this was DevTools because it does a similar override, and I was pinged on this issue. You're right though. It looks like this is a React Native override: react-native/Libraries/Core/setUpDeveloperTools.js Lines 62 to 81 in b7c14f2
Which makes sense, given that the console screenshot above shows Looks like this change maps back to a recent commit "Improve console logging to Metro": |
Checking whether console is native or not and skipping the Metro logging setup makes sense to me. Do you wanna send a PR for that? |
Summary: This diff fixes an issue reported in facebook#26788 where logs in the Chrome console were showing a different location than previous versions. In the change here, we stop wrapping the console functions to attach the metro websocket in any environment that isn't a native app environment. We do this by checking `global.nativeLoggingHook` which is bound only by native apps and not environments like the Chrome DevTools. Differential Revision: D17951707 fbshipit-source-id: 64b143c4d256e6ab13150dad2702b12cc4500391
This is fixed by #26883 That diff will revert this back to showing "YellowBox.js": This will stay the case until Chrome exposes a way for us to ignore our wrapping frame (see here). Until then, if you want to see the true frame, you can blackbox Note: The regexes to use are Note: Notice that You can read more about Chrome Blackboxing here |
I just applied this patch and chrome console logs work again for me and it's showing the correct files/ line numbers as before. |
Sorry for my ignorance, but how do you apply the patch? Well for now I just manually changed the file. |
Manually modify the react native core file in node_modules as per the commit here: 77acfd7 |
When will the patch fix be merged into the repo? |
It will be merged when it's ready. Likely next week. |
Summary: Pull Request resolved: #26883 This diff fixes an issue reported in #26788 where logs in the Chrome console were showing a different location than previous versions. In the change here, we stop wrapping the console functions to attach the metro websocket in any environment that isn't a native app environment. We do this by checking `global.nativeLoggingHook` which is bound only by native apps and not environments like the Chrome DevTools. Changelog: [General][Fixed] - Fix wrong lines logging in Chrome debugger Reviewed By: cpojer, gaearon Differential Revision: D17951707 fbshipit-source-id: f045ea9abaa8aecc6afb8eca7db9842146a3d872
The fix was merged, we went with a strategy that was a bit better than the original patch tested above so please check it out and let me know if you have any questions 42ac240 |
0.61.3 - Still shows |
Summary: Pull Request resolved: #26883 This diff fixes an issue reported in #26788 where logs in the Chrome console were showing a different location than previous versions. In the change here, we stop wrapping the console functions to attach the metro websocket in any environment that isn't a native app environment. We do this by checking `global.nativeLoggingHook` which is bound only by native apps and not environments like the Chrome DevTools. Changelog: [General][Fixed] - Fix wrong lines logging in Chrome debugger Reviewed By: cpojer, gaearon Differential Revision: D17951707 fbshipit-source-id: f045ea9abaa8aecc6afb8eca7db9842146a3d872
0.61.5: Logcat: ReactNativeJS: 'Unhandled promise rejection', [TypeError: Cannot read property 'reset' of undefined] App showing: console.error: "Unhandled promise rejection', [TypeError: Cannot read property 'reset' of undefined, js engine: hermes
|
index.bundle?platform=andoird&dev=true&minify=false;35761:111 is basically a totally useless line number. |
Summary: Pull Request resolved: facebook/react-native#26883 This diff fixes an issue reported in facebook/react-native#26788 where logs in the Chrome console were showing a different location than previous versions. In the change here, we stop wrapping the console functions to attach the metro websocket in any environment that isn't a native app environment. We do this by checking `global.nativeLoggingHook` which is bound only by native apps and not environments like the Chrome DevTools. Changelog: [General][Fixed] - Fix wrong lines logging in Chrome debugger Reviewed By: cpojer, gaearon Differential Revision: D17951707 fbshipit-source-id: f045ea9abaa8aecc6afb8eca7db9842146a3d872
@tapz that looks like a different issue, it seems like symbolication is only partially applied. If you can repro, can you create a new issue? |
After 0.61.x releases on the debug mode
console.log
commands are not showing their code line locations. They always shown at... Project Directioy ...\projectName\node_modules\react-native\Libraries\Core\setUpDeveloperTools.js:73
directory.For example;
Before update:
After update:
Is this a bug? If it's not previous version was way more useful for variable, data or etc.. tracking.
Versions:
Environment:
[skip envinfo]
The text was updated successfully, but these errors were encountered: