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
Related
I am using google closure compiler to compress all the javascript into single file.
While compliance it give lot of warning messages.In my case I have already compressed third party JS files, Which causes complete file to be printed on browser (i saw build progress in browser) for a single error. I cannot modify third party js due to licenses issue.
I am getting tons of warning messages with complete code in browser window, which causes browser to be hanged.
How can I suppressed all the warnings for particular file.
Use the --hide_warnings_for=node_modules/somelibrary flag.
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.
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 developing a Symfony2 application using PHPStorm IDE.
I can't seem to make it work. I've tried Javascript Debug for both local and remote with multiple parameters. Messages varies from "Remote URL isn't specified for so breakpoint..." etc.
Best case scenario is that I would be able to debug my Javascript codes inside PHPStorm. Is this possible?
I'm also using AsseticBundle for my assets.
I use PHPStorm too but I only use it for coding, debuging is in browser..
So I would say it depends on if PHPStorm executes the app_dev.php and graps the output.
If you already have experience with PHPStorm (Debuging) you could answer this. I myself don't think so...
Hope I could help at least a little :)
JavaScript debugging is definitely possible from the PhpStorm if you are using Chrome or Firefox browser. Debugging JavaScript and PHP at the same time is not supported at the moment.
I was able to set this up
Install the JetBrains Chrome extension
In PHPStorm click the Run/Debug Configurations just to the left of the green bug near the top right
Add a Javascript Debug (using the plus sign)
In the URL box, just enter the URL of the page you're debugging (e.g. http://my.test/app_dev.php/route/here/not-there/3290), name the config, and apply
Add breakpoints in the js
Make sure dev tools is closed in the browser, then click the green bug (ensuring that the config named in 4 is chosen) and it will redirect to the page specified in 4.
The breakpoints will now be activated and are able to be stepped through (like xdebug). When it stops on a breakpoint it may be in a version of the original file with the file's name appended with a version number (this file is read-only). There is a button to the left hand side of the name where you can reload the read-only file being stopped at, after you have updated the actual (writable) file.
I have a web page which includes insane amount of minified JS files. The web page works perfectly fine on my local network but throws some JS error on staging. There is an issue in JS and I wan't to debug it. When I load the JS in Firebug's script tag it appears in one long horizontal line. Is there a way out in Firebug that expands or beautifies the script for debugging? I know I can use jsbeautifier but they wont help me. I can not upload an expanded file to CDN, defeats the purpose of using CDN.
Points to be noted,
a) I can not control the box which serves JS, its on CDN, I mentioned it.
b) I can use beautifiers etc but would that help me in debugging the script in run time? IMHO, no
c) Being bound by NDA and other legal things I can not share the script but its a generic problem, you can encounter it with a minified jQuery
Beautify your script
Add the CDN host in /etc/hosts or your local DNS to resolve it to your own web server
Host the beautified version and everything that you need on said web server
Both Firefox and Chrome (versions as of this edit) support beautifying script with the {} button available in the inspector.
Just load the minified file and press the {} button at the bottom and it instantly beautifies, making breakpoints and other debugging possible. (True for Chrome too)
This is a common problem and the Chrome dev team have recently come up with an elegant solution, which they've called Source Maps - see http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ for more info, I think you'll find it's exactly what you (and the rest of us) have been crying out for! :)
This is more a workaround, but it can help. The idea is that we will replace files coming from the server by files on your machine.
This will work with any browser.
It takes a bit of setup the first time (15 minutes maybe), but then it can be very convenient.
It can also helps testing your bug-fixes in a live/prod environment.
Get Fiddler (it's a web debugging proxy), install it, run it.
http://www.fiddler2.com/fiddler2/
(Restart browser after install to get the Fiddler extension)
If you debug an HTTPS website, check this first:
http://www.fiddler2.com/Fiddler/help/httpsdecryption.asp
From now on, you should see in Fiddler ("Web Sessions" pane on the left) all downloads made by your browser, including JS files.
If not, check this : Fiddler not displaying sessions
Find the file you want to debug in the list (Ctrl+F works)
Click on the file. Then either:
get the file content from the inspectors pane (textView tab), beautify it, save to a file on your local computer
or have access to a file which contains the source code (ex: from your source control)
Go to AutoResponder tab (top left pane).
Select "Enable automatic responses" checkbox.
Select "Unmatched requests passthrough" checkbox.
Drag your file from left pane to right pane (prefills rule editor at the bottom)
Set the other field with the path of your local file
Click the Save button
Reload the page and enjoy your debugging session.
Fiddler can do many more things, but this use-case answers the initial question.
Consider a Change!
Firefox w/ Firebug was my favorite JavaScript debugging method for almost a year, but I've recently moved to Google-Chrome's Developer-Tools which is far more superior.
Chrome supports an On-The-Fly (built-in feature) beautification of JavaScript resources
Once beautified, you are free to debug the JavaScript resource file, as it was "natively" downloaded beautified from the web-server. Breaking-points are set by clicking the line number.
One of the most extremely powerful feature,
Is once You've Stopped In A Breaking-point, You Are Free To Execute Commands (using console) In The Same Scope You ARE In The Breaking-point. In Firefox you can't do that.
Its so easy to debug (even anonymous functions), You'll never be back to Firefox.
Try It!
Pretty-print your JavaScript. Google this and you'll find multiple on-line JS beautifiers.
I happen to use http://jsbeautifier.org/ myself and it works fine, but search for others and use one that suits your needs.
Caveat: You still won't be able to get meaningful local variable names (which are usually renamed by a minifier). If the code was compiled by the Closure Compiler, then you absoutely won't get any useful information back at all, even when beutified, because then all variables and functions and properties are mangled (not only local ones).
Now, if your problem is with debugging code that comes from outside (e.g. a CDN), obviously that code would be minified, and you can't save your beautified version back there. In this case, you can replace the tags that load code from a CDN with a url pointing to your local version, then you can beautify the code (downloaded from the CDN) into your own server and you can then debug with FireBug.
Now, if you don't even control the HTML that contains those tags (e.g. they reside on a outside server), then unfortunately there is no way for you to do what you want without physically downloading the entire site to your own server. Even if you downloaded the entire site (with all the files), it may not work since the site may be driven by a back-end processing language or accesses a back-end database. In such case you'll also need to simulate all those data. It can be done, however -- you just have to go through a lot of pain. My recommendation is to save a version of the web page and run it on your own server, serving beautified code from your own server to debug.
Placing breakpoints on JavaScript makes debugging much easier, but if your code has already made it to production then it's probably been minified. How can you debug minified code? Helpfully, some of the browsers have an option to un-minify your JavaScript.
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.
In Internet Explorer, click the tool icon by the script selection drop down to find the option to format the JavaScript.
Opera will automatically prettify minified JavaScript. Source