I'm troubleshooting a problem in my React.js app and I'd like to view the actual javascript being executed in the browser after it's been transpiled by Babel and bundled by Webpack. What's a good way to do this?
The app uses create-react-app so it has the default CRA configuration for Babel, webpack, etc. Source maps are working (good!) but what if I want to peek behind the source maps to find the real code being executed?
I know that I can find /static/js/bundle.js in Chrome Dev Tools' network pane, and then use Cmd+F to find a piece of code in that huge file. I also know that Chrome Dev Tools has an option to turn off source maps, but changing a persistent setting (even if I can do this without restarting debugging, which I'm not sure I can) doesn't seem any easier than the Cmd+F approach above, especially because I'll then have to remember to change it back (and restart debugging again?).
Instead, I'm just looking for a way to flip back and forth between actual generated (transpiled and bundled) code and my (source-mapped) code without interrupting my debugging workflow.
Is this do-able in Chrome?
Related
Can someone please explain what the point is of source maps? Because as I see it, my concatenated and minified file gets loaded (talking about JavaScript), alongside 100+ modules. How is this not affecting performance when I'm loading twice the size as before?
The point of a source map is that you can run minified Javascript or transpiled Javascript (which is not particularly readable in a debugger by itself), but when you open the debugger, the source map is loaded by the debugger and it gives you a readable form of your source for debugging purposes. The source map is not loaded if the browser is not configured for source map debugging.
Source maps are also extremely useful if you are transpiling code from something like TypeScript or ES6 down to ES5 Javascript so you can see the actual code that you wrote originally in the debugger rather than only the transpiled and minified output.
The alternative before the days of source maps was to have separate versions of your site or options on your site that would load non-minified JS so that you could debug with normal symbols, but this of course isn't actually debugging the exact same code so even then, this could still leave you having to try to debug minified code.
You can read here about how source maps are enabled in the Chrome debugger. If you're watching what is downloaded by the browser, then make sure that you are using a browser that does not have source maps enabled when checking if they are downloaded.
Because you only load the sourcemap when you open the debugger.
Actual users, who don't open the debugger, still get the benefit of the minification.
A source map is a developer tool. It's practical to know the original source when an error occurs within minified source, so you can track down the source of the error.
Source maps are thus only loaded by debuggers, and will not be loaded by default. However, you should consider disabling source maps for production environments, because debug data usually shouldn't be on production environments: for performance and (more importantly) security reasons
Although I used pretty code and had set up the breakpoints in "Pretty code" tab, debugger keeps working in minified code. (I can't see exactly where I am and need to continuously switch between source and "pretty code").
On same pages with same script it sometimes work and sometimes don't. I can't find the cause or any difference in the way I activate it.
Is there any way to force debugger to use "pretty code"? Any Ideas or additional questions? Should this be reported as a bug?
EDIT: I still don't understand what is going on but there is a fix for it. So when this situation happens, just edit script and add "debugger;" keyword after the cursor. It will make a breakpoint. Then, if you use "pretty code", debugger will stay inside prettified code. As I said, I don't understand why is this happening so I'm still waiting for answer(s).
EDIT: Current browser version is 42.0.2311.135 (64-bit).
EDIT: Dave pointed out that there is a reported bug on something very similar. https://code.google.com/p/chromium/issues/detail?id=415406 It says it's related to file size but I can't confirm this. I changed title to reflect these findings.
In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file and then press the "{ }" (pretty print) icon located in the bottom panel.
You can call this a bug. You can call it a dillema.
Open ticket from Aug 9, 2013
(Chrome v. 28)
Bug Reporter's observations
I've been spending some time debugging this, and familiarizing myself
with how to develop devtools locally; I'm not sure if all of this is
helpful, but here's a braindump of what I've looked at so far and some
hunches:
When attaching a breakpoint in the original .js file, the UI seems to
get confused and assigns the breakpoint to the associated .coffee or
.ts file per the sourceMap association [see image-1, attached]
However, when unchecking the breakpoint to disable, the UI correctly
updates to show the breakpoint in the right place in the .js file.
[see image-2, attached]
It seems to me there is either an incorrect lookup happening in
WebInspector.CompilerScriptMapping.rawLocationToUILocation or
WebInspector.CompilerScriptMapping.uiLocationToRawLocation
Open ticket from Sep 21, 2014
(Chrome v. 37)
Chromium Developer's Observation
This is not something that could be solved easily. The breakpoint
manager is build around the idea that the breakpoint is always shown
in the "best possible" UI location, which is uncompiled source in case
of source maps. Fixing this would require us to use breakpoint's
primary ui location as a hint to where it should be shown. Moreover
since execution line will be shown in the uncompiled sources by
default, it is essential that we keep showing our breakpoints in them
as well. So this all ends up in the need to show breakpoints (and
execution line) on several ui locations at the same time. All actions
with these locations should work smoothly etc.
This is a significant effort and does not sound like a "GoodFirstBug"
to me.
Conclusion:
Prettify does not seem to create a new non-minified version. Rather it is rendered. This makes sense. With all the different frameworks and flavors (e.g. Coffee), if the debugger created a new file, there is high potential for error.
The breakpoint
manager is build around the idea that the breakpoint is always shown
in the "best possible" UI location, which is uncompiled source in case
of source maps.
I interpret this to mean the Chrome browser and debugger will continue running from the minified version. When you set a break-point in a "pretty" file, the debugger sets it in the minified file and gives the developer a "pretty" rendering of debugger stepping through minified file.
This is a lot for the debugger to manage, and can be rather fragile. We can call this a bug or a very ambitious feature for which many things can go wrong.
**
I have added this thread to both bugs and emailed both developers assigned to it.
**
As of 2020, similar behavior still occurs in a specific situation:
You open a source-mapped document, i.e. it shows "(source mapped from ...)" on the bottom of the window
You prettify it
You place a breakpoint in the prettified version
The debugger will stop in the ugly source-mapped file
The solution seems to be to go to the original source from which you mapped, prettify that, and place the breakpoint there.
Chrome 79.0.3945.88 ; Webpack 4.41.2
Seems like you are clicking the "{ }" (pretty print) icon located in the bottom panel and setting a breakpoints there without attaching a source map of the original file.
When given a .map file, Chrome dev tools and map each line of executed minified code to the original source file using the data in the .map file. Otherwise it will just do it's best to indent/format the minified file.
I suggest you use grunt uglify or similar to minify your js which will automatically generate a map file for debugging. See the following links for more information on how to do this.
http://blog.teamtreehouse.com/introduction-source-maps
Javascript .map files - javascript source maps
How about this?:
Generate the pretty-print version of your "min" version and save using your "min" version name: Substitute the "min" for a pretty "one"
simply put debugger; at top of the js code.
ex:
function add(n1, n2) {
debugger;
let sum = n1 + n2;
return sum;
}
To debug a third-party npm library during local development.
Update package.json from "node_modules[package_name]\package.json"
"main": "dist/package-minified.js" -> "main": "dist/package-formatted.js"
Rebuild your project
You will be able to set a breakpoint to the third-party js library.
Usually, libraries come with both formatted and minified js files. You will find them under node_modules[package_name]
dist/[package-name]-src.js
dist/[package-name]-min.js
I need to test a fix, and only production data is failing (and a tangled nest of foreign keys prevent copying data down to test).
The JavaScript fix is simple, 2 or 3 lines to section_functions.min.js.
I open dev tools, click the sources tab, drill down to the file... edit it. I do a cntl+s, the star disappears from the file's tab in Dev Tools.
I then use the web app's interface in such a way that the altered function in that file should be invoked...
But in the console, I get my same error as before and it's telling me the exception is on /js/section_functions.min.js (old):1 .
I know that it's possible to edit the javascript live in this fashion, and I must be doing something boneheaded that is preventing it from using the modified version. What am I failing to do correctly?
there is a usefull trick, add a sourcemap to your compressed js file so you can see and edit the code in beauty way.
other way faster to it is using the {} buton in the chrome tools it is in the bottom of the file in the left of line and column number
when you have it looking good you can edit it.
Good luck
Set the breakpoint
Refresh the page
Redefine the function or variable
Save the JavaScript file
References
Get Started with Debugging JavaScript in Chrome DevTools | Web | Google Developers
Debugging Chromium on Windows - The Chromium Projects
Featured DevTools Extensions - Google Chrome
Set Up Persistence with DevTools Workspaces | Web | Google Developers
JavaScript Debugging Reference | Web | Google Developers
Debugging Node.js with Chrome DevTools – Medium
What is the industry standard or professional process of finding out where the actual line number in the source code of your rendered page is happening?
I have used browser debug tools and it of course shows you the error, but the line number is not the same for the source code file that is being served up. I know that usually server side scripts are making the file longer than it really is and etc.
I usually just do a find for functions or code near the error and can eventually find it, but is there a better way?
The simplest way is to ensure that most of your JS is written in non-templated .js files, rather than inline <script> blocks in your templated html.
I develop with Visual Studio.net 2013, which will stop at breakpoints and break on server and client side errors.
If you aren't developing with a tool like VisualStudio that has a built in debugger with breakpoints, etc., the built in developer tools in Chrome and IE are awesome (IMHO). Since Javascript runs clientside, you'll need to debug it using the browser. If you don't like the built in developer tools, you can also try Fiddler and Firebug.
I'm trying to debug an AngularJS app in Chrome (with the Jetbrains extension) within Webstorm 8. It's working just fine, but the only naggy thing is that the actual file that has breakpoints in it doesn't get debugged, but a readonly copy that reads as the full url of the file is (see screenshot). It works, but I cannot edit the readonly file while moving from line to line.
edit: plus, the IDE usually shows an outdated version of my JS file and I have to manually refresh it to see the correct one.
The Webstorm Run/Debug config for Javascript is really straight forward, basically just the URL to the app.
Does anyone knows how to avoid this?
Cheers
The short answer is: you can't
The longer answer is, the computer is not running the code that you see on the screen, that's just what the debugger is showing you. The computer is actually running optimized, non-human-readable Javascript bytecode, which is created when you start your JS program, after syntax is checked, namespaces are created and memory is allocated for variables etc. You can't edit that bytecode by writing JS code directly, at least not with any debugger I know of (and I'm fairly certain you can't with Webstorm specifically; I use PHPStorm and its Javascript debugger).
Such problems usually mean that remote files are not correctly mapped to local ('remote URL' not correctly set for local files in Run configuration), so the debugger can't map the files being executed to your actual sources. I'm not sure what your application looks like... But, as Angular apps structure is more or less standard, I can suggest mapping the 'app' folder to 'http://localhost:9000' in javascript debug run configuration you are using to debug your angular code