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.
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
Should source-maps be used in production environment? Do they provide any benefits other than debugging?
Do they impact app load time due to the additional server round-trips? Are browsers smart enough to load .map assets after app is loaded and rendered?
If a browser cannot find the .map asset (404 error), would there be performance impact? Should I care about fixing it?
Note that fixing the last one may not be as easy as serving the .map assets if there are complicated concat / minify build steps.
A quick test using Charles Web Proxy shows that source maps are only loaded if developer tools are opened. If you load a page without dev tools opened, there is no http request for source maps.
The behaviour was the same in Chrome 43 and Firefox 38.
So it appears they would be no impact on production environment.
From HTML5 Rocks:
Basically it's a way to map a combined/minified file back to an
unbuilt state. When you build for production, along with minifying and
combining your JavaScript files, you generate a source map which holds
information about your original files. When you query a certain line
and column number in your generated JavaScript you can do a lookup in
the source map which returns the original location. Developer tools
(currently WebKit nightly builds, Google Chrome, or Firefox 23+) can
parse the source map automatically and make it appear as though you're
running unminified and uncombined files.
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
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
I am in the process of implementing a feature on a Python webserver which automatically fetches, concatenates, minifies, caches and serves Javascript files (including external ones) on first request so that users can get the benefits of minification without us having to manually run any of our Javascript through a minifier when we push changes.
However, the trouble is that our choice of minifier (slimit) introduces a syntax error somewhere in the Javascript, and (naturally) removes all newlines.
Simply knowing that there is an Unexpected token ILLEGAL somewhere in our hundreds of thousands of characters of minified Javascript is unhelpful when trying to figure out the cause of this and find a workaround.
So:
1) Is there a way, in (any) browser, that I can automatically 'prettify' Javascript when viewing it in the Developer Tools section of the browser, inserting line breaks after statements, and showing errors on the lines where they occur?
2) Alternatively, is there a clever hack I can use before returning the minified Javascript on our testing server to insert newlines at the end of statements wherever possible, in order to make it easier to find the location of the syntax error when viewing in Developer Tools?
3) Alternatively, is there some other obvious solution to my problem that I am missing?
if you are using / or can use chrome to debug then there is an option to see the minified files in pretty print
press f12 -> Sources -> Select the javascript file to debug -> select pretty print from the bottom bar.
this will set the right format will all the tabs on the minified file and probably you will be able to find the error