There are many situations where we want to see what's wrong with out code without the trouble of changing source code and push the changes again, r...
For further actions, you may consider blocking this person and/or reporting abuse
Great article, it's nice to point that developer tools can be attached to the nodejs even on the remote :) In my work, a lot of people use console.log() because they don't know how to connect devtools to the server on the remote.
I had the same thought when reading the article - when I am debugging a TypeScript-based app, the breakpoints are often not very useful.
console.log()is crude, yes, but gets the work done.I like using debugger; in chrome, it’s kinda the middle ground between console.log and only using the inspector.
I like that it’s less transient, I can add it and jump right back in if I have to pause debugging a problem and come back later. :)
Git stash does not work for our browser debugger.
I also use console.log for the same reason, I can save something I am debugging for later.
No you won’t put source maps in prod, but in test or uat where it’s close to prod, but I don’t assume you put console.log in prod either, or wait for how many minutes your build will take for each debugging session
You can connect your browser to vscode for example and with sourcmaps you dont even need to debug in the browser but in your Editor/IDE directly :)
You can add console.log statements in Chrome without access to the source code via log points. See: dev.to/joeattardi/in-defense-of-th...
I wish this was a video .. very good article.
Thanks for the good post. It's really annoying to dig through browser extensions' content scripts to get to the code you're interested in 😂
Classic article but still pretty hot: I am a puts debuggerer
i (have to) do this and yes, it's a PITA.
Source map is all you need.
I don’t think anyone will put debugger statements in production either