This question was answered with configuration for webpack. I am trying to get source maps working myself and wondering why chrome (and firefox) are not respecting the comment
//# sourceMappingURL=main.js.map
I thought I should see a network request to the server in devtools for the map file, right? Why is that not happening and how do we modify the main.js file created by webpack OR the *.js file created by our other tools such that it works without configuring chrome developer tools like was done before. I figure since both firefox and chrome are not working, there must be some new standard I am missing? (but not sure since webpack does not seem to do it properly?)
Firefox says it should be just do the above here -> https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map
Related
I have been happily using the Chrome development tools for some five years to debug my Angular/node.js code. I open the Chrome development tools, click on the "sources" tab, navigate my way to the "Webpack" link on the left, and find my way to the directory of all my Javascript source and away we go. Among other matters, the good folk of Chrome have continually improved the debugger over the years: it is a beautiful thing. I have been very happy.
Until this week, when suddenly the Webpack disappeared from the source options. I can see lots else (essentially, all the javascript referenced direct from the index.html file) but the webpack is not there. Nor is it accessible in Safari. But it is still there in Opera and Firefox.
What is going on? I can not be the only person who routinely uses Chrome to debug a webpack application. Help, please.
Here is a screenshot of what I see in my browser. First, as it now appears WITHOUT any Webpack access, in Chrome:
Second, as it still appears in Firefox (and Opera) with Webpack and all my stuff:
Update! I've found the code in Safari. But it no longer appears under the label "Webpack". Instead, it appears under the site URL-->dist-->app.bundle.js (which appears as a folder containing all the code files, thus:
However, app.bundle.js in Chrome is NOT a folder; clicking on it brings up this message:
Yes, I can see that I might here be able to use the "Filesystem" tab to import the files from my development system, and to edit and debug them directly in the debugger while running the app on a local host. Very neat. But actually, there are many times I need to be able to dig inside the app on the production system. I can still do this on Safari, Firefox, Opera. But not now on Chrome. Why not?
UPDATE! I have been digging yet further. Not only is it only Chrome that has this problem. It appears that it is only Chrome on an M1 chip Mac running Big Sur. And digging still deeper: when I look at the app.bundle.js file I discover -- lo and behold! -- all 13000 lines of my code, originally distributed across some 60 component.js files, appears in this one indigestible mega file. Yes, I could find the bit I am working on in there and debug it. So Chrome developers: how come the Safari folks are able to deconstruct app.bundle.js back to the original file structure and you guys cannot?
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?
I am trying to get my Webpack project to have a source map file.
I finally got the settings right so that it would do that, but now I am getting this error:
DevTools failed to parse SourceMap: http://MyServer/MyApp/bundle.js.map
I go to the URL it states and I find a json file with these properties:
version - Set to 3
sources - very long array of strings that seem to be webpack paths to my files.
names - very long array of strings that seem to be random variables and functions.
mappings - very long string of seemingly random capitol letters and commas.
file - set to bundle.js
sourcesContent - Very Very long array of strings (over 10 million chars). All my source code.
sourceRoot - set to empty string
It all seems to be valid json. Unfortunally Chrome gives no reason why it failed to parse the source map.
Is there a way to get Chrome to say why it failed parsing the source map?
Or, failing that, does anyone know why my source map would fail? (My code is way too large to post, but here are my webpack.config.js and my package.json files.)
NOTES:
I have tried this with webpack 2.2.1, webpack 2.3.2 and webpack 2.6.1.
Source maps work fine in IE 11 and Firefox.
If I inline my source maps, then they work fine in Chrome DevTools, but then my bundle.js goes from 3 MB (already too big) to 16 MB (WAY too big).
I have set "Enable JavaScript Source Maps" in settings (and the CSS one too).
I tried using Chrome Canary, but it had the same issue.
I am hosting in IIS.
It is not an answer to this question, but i believe my answer can help some people.
This is due to the settings of chrome, for example in FF this error warnings not happens.
To fix it go to Developer Tools Settings of Chrome, and uncheck:
"Enable JavaScript source maps"
"Enable CSS source maps"
Then refresh Chrome.
In order to debug js and scss minified files, this tells the compiler where the source file is actually mapped.
Using last versions of Webpack source-map work well,
I tried to reproduce this bug, but without possibility to run a project, i can't see what a problem of author of a question.
This warning happening for example using angular, and sourceMap should be set true in angular.json, or other way if you don't use source-map'ing' and you don't want see this warning disable it in browser following my answer.
From experience, I wouldn't expect a client to tell you why it couldn't parse a SourceMap (although that would be nice). I have run into issues with some tools being unable to parse large source maps (probably memory constraints), and given your large asset size, I would look at that first.
Webpack supports several different values for the devtool config field, and some of them are less faithful than the default. Have you tried, for example, 'cheap-module-source-map'? Getting line numbers only (no columns) is a fine trade off for a usable source map IMO.
But it will probably serve you better to reduce the asset size. Webpack's code splitting and 'chunk' management options make it pretty straightforward to split your code into multiple files that are loaded async at runtime. In this case you would have two or more JS files, and each would have its own source map, so the browser will no longer choke trying to process one big file.
In my case, I had to disable Adblock to get rid of the error.
It's possible that some chrome extensions are messing with DevTools.
Perhaps, you could try disabling the ones you do not need for your particular app and see if that "fixes" the problem.
Above is the approach that worked for me but I'm not really sure why it does.
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
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