I'm trying to get CoffeeKup to work with Mozilla's Rhino engine. Not much luck so far. I'm trying this simple template:
templates ?= {}
templates.first = ->
doctype 5
html ->
head ->
title "#{#title}"
body ->
h1 "#{#hello}"
Which I compile into Javascript and then try to render using
CoffeeKup.render(templates.first, {title: 'Say Hello', hello: 'Hello World!'});
But it fails with this:
org.mozilla.javascript.EcmaError: SyntaxError: invalid return (CoffeeKup#304(Function)#230)
In the Javascript version of coffeekup.coffee, line 304 is this one:
return new Function('data', code);
And code line 230 (last line) is this:
).call(data);return __ck.buffer.join('');
Does anything look out of the ordinary or is this perhaps a Rhino bug?
If it works on Node/V8 + browsers but not Rhino, you can be fairly certain it's something specific to Rhino (not necessarily wrong, though). In the longer comment at the top of coffeekup.coffee it says that it will run on Node or on browsers, so that's most likely the case.
To really know what's going wrong, you need a debugger where you can step through the code (I don't know how to do that on Rhino, possibly via Eclipse or maybe even jdb if you have all sources at hand and are very Java proficient). If you find something reasonable trivial, try to file an issue, but CoffeeKup doesn't seem to have seen much activity for the last months. If you're up for a challenge, fork, fix and pull request.
Related
Liferay 6.2. tries to use best practices and JS minification is one of them.
But what do you do when your unminified JavaScript works and minification produces errors like this (in Tomcat console):
12:23:48,794 ERROR [http-bio-8080-exec-10][MinifierUtil:111] 607: 21: identifier is a reserved word
12:23:48,797 ERROR [http-bio-8080-exec-10][MinifierUtil:111] 608: 45: identifier is a reserved word
12:23:48,802 ERROR [http-bio-8080-exec-10][MinifierUtil:111] 1: 0: Compilation produced 2 syntax errors.
12:23:48,805 ERROR [http-bio-8080-exec-10][MinifierUtil:88] JavaScript Minifier failed for_________ AUI().use('node', 'aui-base', 'aui-io-request', 'aui
[MinifierUtil:111] 607: 21: and [MinifierUtil:111] 608: 45: are not line numbers in your code (jsp/ftl/...) as man expects from console log and googling "identifier is a reserved word" or "JavaScript Minifier failed for_________" helped me almost nothing (ok, I knew about https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#Keywords normally).
Pasting code between <script> and </script> to JS lint or hint or any other JS tool is not an option as it contains many JAVA and spring/freemarker/liferay tags etc...
So - my question is - as I wasn't able to find best practices / methodologies for debugging this - what is your opinion (or even better - experience :)) ?
Well, you solved the problem in another way - just some pointers should you (or someone else) run into this issue again:
Minifier reports Line number and Offset in these error messages, but they're related to the content that the minifier sees - e.g. not in your JSP, FTL or other file, but in whatever gets passed to the minifier.
The way to read the minifier log is:
Line 607, column 21 as well as Line 608, column 45 have a problem
In the following line, you see JavaScript Minifier failed for_________ AUI().use('node', 'aui-base', 'aui-io-request', 'aui which is the first part of the content that the minifier sees - locating this code, you might be able to identify which content gets passed to the minifier and count down the lines (well, jump down 607 lines from there)
Side issues: Agreeing with #Origineil that the startup time rather points to another issue that you have - it shouldn't be that much unless you deliberately have processes running at startup. E.g. if you're running a cluster and each machine keeps its own lucene index, you must reindex at startup. If you want to work around that, two indexes might not be what you're after. But it's only an example, and you didn't ask for this. I just wanted to add some pointers. I assume that you have tuned your JVM memory settings already and are not running with the default bundle's settings?
I finally managed to solve the problem by:
copying the rendered (and unminified(!)) code between <script> and </script> and
paste it to JShint/lint/online minifier and re-check it there,
but I still wonder if there is some better way... (changing server properties from developer to production and back means restarting server few times at least and that takes about 300 seconds (only for restart) on my new(!) i7 vPro 64GB, SSD HDD workstation, so I try to avoid it as much as I can :)).
BTW: unminified code had some "deprecated" but simple ECMA methods that worked normally in JSFiddle and all latest browsers on my Win8.1...
I'm having trouble integrating bitovi syn (link), Rails 3 (asset pipeline), Ember and qunit. I want to use syn for browser simulation for testing purposes. Has anyone done this, if so, how?
I'm using the version of syn that was released 11 Mar 2014. When I load it into my app, two things happen:
I get a global failure in qunit that says "TypeError: 'undefined' is not an object (evaluating 'Syn.schedule')", (around this line: syn.js?body=1:1084)
and
A div with a form is added to my application.
I'm using qunit for the most part, and I dabbled with using YUI to do browser simulation but it isn't working quite the way I had expected it to. I'd really like to use Syn, but I don't understand why it's not working.
In attempting to get it work, I tried adding this line to the top of the syn.js file:
window.Syn = { schedule: function (fn, ms) { Ember.run.later(window, fn, ms); } };
but it didn't do anything much at all.
I'd read on this pull request: https://github.com/bitovi/syn/pull/28 that I could add that piece of code to mount it in a fashion to work with Ember.
Any help would be greatly appreciated!
So the thing here was simply to load Syn at the bottom of the page. It's potentially a bit broken at the moment in the case where you want to load it in the head (which I probably shouldn't have been doing anyway, but still!) :)
Original Question
This maybe a stupid question but is there a way in VS 2013 to unminify JavaScript?
Just making sure we are all on the same page here.
Minify:
var flashVer=-1;if(navigator.plugins!=null&&navigator.plugins.length>0){if(navigator.plugins["Shockwave Flash 2.0"]||navigator.plugins["Shockwave Flash"]){var swVer2=navigator.plugins["Shockwave Flash 2.0"]?"
That's just an example to make sure we all know what I'm on about. As far as I can tell there is no way to be able to do this. I have only been using VS 2013 for around 3 weeks so there is probably still stuff that is hidden to me.
If there is no way to do this within the program what is the next best thing for this?
I did see on another similar post that recommends the site http://jsbeautifier.org/ , so may have to give that ago but would make life easier if it was built into VS 2013
Thanks in advance as I know someone will be able to help me out here.
Update:
I have looked around VS 2013 and found nothing that can help me with this problem, like I said before they maybe some things I have missed (certain settings) so I guess if it cannot be done in VS what's the next best thing for the job? I seem to run into a fair amount of JS that is minifed and would like the quickest and best way to get the job done. I couple sites I have tried seem to have problems with it, is there a program I could install that would just allow me to short cut it with a hot-key or something. That would be pretty handy.
Update 2:
So I think its safe to say this cannot be done within VS2013, or for that matter at all due to missing var names and so on. So I have seen a few links and programs that allow you to format the code. Is there a way to do with within VS2013? And again if not what is the most reliable website/program that I can use to do this. Like I said I can see there have been answers and I appreciate all of them. I will be leaving this question open for a while to get more people to look at it and possibly give a better answer. Keep it up guys!
Update 3:
If anyone has any more information on this please do share. I am still looking around now and then waiting for someone to come up with something amazing for this. One day people.... One day!
The thing is that you cannot really "unminify" your code since some data was already lost - e.g. variable names. You can reformat it to more readable form though.
According to this question, since VisualStudio 2012 you can just use Ctrl+E, D keyboard shortcut
If the above is not right, there is this extension for VS 2010: http://visualstudiogallery.msdn.microsoft.com/41a0cc2f-eefd-4342-9fa9-3626855ca22a but I am not sure if it works with VS 2013
There is an extension to VisualStudio called ReSharper which can reformat javascript in a few different manners.
Also there are online formatters already mentioned in other answers (if your code is confidential, I would advise some paranoia manifested by downloading sources and using them locally).
Also you may always try to find unminified version of desired library on the interwebs
Also, there is the WebStorm IDE from JetBrains that is able to reformat JS - you may download a trial for the sole purpose of reformatting your minified scripts :)
If that's just to make debugging easier, you may want to use source maps
Also, here is a bunch of related questions:
How to automatically indent source code? <-- this is for VS2010, but it looks promising, maybe it will help you if it supports JavaScript (and it does since VS2012 according to MS support):
Ctrl+E, D - Format whole doc
Ctrl+K, Ctrl+F - Format selection
reindent(reformat) minimized jquery/javascript file in visual studio
Visual Studio 2010 can't format complex JavaScript documents
Visual Studio code formatter
how to make visual studio javascript formatting work?
I am not sure if they figured out a working way to reformat JS, but I've seen a few answers which might be helpful - I am just pasting this in here just FYI.
Added 03.06.2014:
http://www.jsnice.org/
This tool could be useful too, it even tries to infer minified names. As stated on their website:
We will rename variables and parameters to names that we learn from thousands of open source projects.
Personally I can't think of a reason to ever unminify code^:
If you're using a compiled js file (a-la google closure) and want more readable code to debug, use source maps available for well-supported libraries (speaking of jQuery, if it is served from a google CDN it already maps to the correct source)
If you're using a whitespace-only minified js file and want more readable code to debug, you could just toggle pretty print in-browser. This seems to best fit your question.
If you're using either of the above and want to modify the source code for a third-party js file, don't. Any future release will cancel out your change - instead consider one of the many patterns to extend a framework (or, perhaps, do some duck punching depending on the exact scenario.)
The other answers seem to cover the "unminification" process (maxification?) well, but it's worth making sure it's a necessary step first.
^ - Except when version control falls over, there are no backups and the only version of the file left is a minified copy in browser cache. Don't ask.
Its just a one way transformation .... sorry in normal cases you will not get something understandable back from minified JavaScript !
Make just a quick look at JQuery source for a second:
(function( window, undefined ) {
// Can't do this because several apps including ASP.NET trace
// the stack via arguments.caller.callee and Firefox dies if
// you try to trace through "use strict" call chains. (#13335)
// Support: Firefox 18+
//"use strict";
var
// The deferred used on DOM ready
readyList,
// A central reference to the root jQuery(document)
rootjQuery,
// Support: IE<10
// For `typeof xmlNode.method` instead of `xmlNode.method !== undefined`
core_strundefined = typeof undefined,
// Use the correct document accordingly with window argument (sandbox)
location = window.location,
document = window.document,
docElem = document.documentElement,
// Map over jQuery in case of overwrite
_jQuery = window.jQuery,
// Map over the $ in case of overwrite
_$ = window.$,
// [[Class]] -> type pairs
class2type = {},
// List of deleted data cache ids, so we can reuse them
core_deletedIds = [],
core_version = "1.10.2",
------
And now at the minify source:
(function(e,t){var n,r,i=typeof t,o=e.location,a=e.document,s=a.documentElement,
l=e.jQuery,u=e.$,c={},p=[],f="1.10.2", ....
I think now you see it =>
window => e
undefined => t
readyList => n
rootjQuery => r
core_strundefined => i
location => o
document => a
So its mapped somehow to make it more shorter look here to minify something
People normally use this so there is no way back
you can just format it look here
If the code has only been minified then the best you can do automatically is reformat to make it more readable. One way of doing this is using an online formatter/beautifier. E.g. Copy and paste the line of code you posted into http://jsbeautifier.org/ or http://www.jspretty.com/ and it'll produce something like this:
var flashVer = -1;
if (navigator.plugins != null && navigator.plugins.length > 0) {
if (navigator.plugins["Shockwave Flash 2.0"]
|| navigator.plugins["Shockwave Flash"]) {
var swVer2 = navigator.plugins["Shockwave Flash 2.0"] ? ""
But of course what these don't do is put any comments that have been removed by the minifier back in. And if the code has also been obfuscated then it will be a lot less readable since the variable names will have changed (e.g. var a instead of var flashVer). See here for further details.
As you can see from the other answers, there is no way to reconstitute minified Javascript back into its original form, it is a lossy compression. The best you can do is make it readable by reformatting it.
If the code is open source, then it is likely that the code will exists in a raw state on some form of version control site or as a zip. Why not just download the raw version if available?
There is an online tool to unminify Javascripts
http://jsbeautifier.org/
And also for CSS
http://mrcoles.com/blog/css-unminify/
Where I work, all our JavaScript is run through a compiler before it's deployed for production release. One of the things this JavaScript compiler does (beside do things like minify), is look for lines of code that appear like this, and strip them out of the release versions of our JavaScript:
//#debug
alert("this line of code will not make it into the release build")
//#/debug
I haven't look around much but I have yet to see this //#debug directive used in any of our JavaScript.
What is it's possible usefulness? I fail to see why this could ever be a good idea and think #debug directives (whether in a language like C# or JavaScript) are generally a sign of bad programming.
Was that just a waste of time adding the functionality for //#debug or what?
If you were using a big JavaScript library like YUI that has a logger in it, it could only log debug messages when in debug mode, for performance.
Since it is a proprietary solution, we can only guess the reasons. A lot of browsers provide a console object to log various types of messages such as debug, error, etc.
You could write a custom console object is always disabled in production mode. However, the log statements will still be present, but just in a disabled state.
By having the source go though a compiler such as yours, these statements can be stripped out which will reduce the byte size of the final output.
Think of it as being equivalent to something like this:
// in a header somewhere...
// debug is off by default unless turned on at compile time
#ifndef DEBUG
#define DEBUG 0
#endif
// in your code...
var response = getSomeData({foo:1, bar:2});
#if DEBUG
console.log(response);
#endif
doStuffWith(response);
This kind of thing is perfectly acceptable in compiled languages, so why not in (preprocessed) javascript?
I think it was useful (perhaps extremely useful) back a few years, and was probably the easiest way for a majority of developers to know what was going on in their JavaScript. That was because IDE's and other tools either weren't mature enough or as widespread in their use.
I work primarily in the Microsoft stack (so I am not as familiar with other environments), but with tools like VS2008/VS2010, Fiddler and IE8's (ugh! - years behind FF) dev tools and FF tools like firebug/hammerhead/yslow/etc., peppering alerts in your JavaScript isn't really necessary anymore for debugging. (There's probably a few instances where it's useful - but not nearly as much now.) Able to step through JavaScript, inspect requests/responses, and modify on the fly really makes debugging alert statements almost obsolete.
So, the //#debug was useful - probably not so much now.
I've used following self-made stuf:
// Uncomment to enable debug messages
// var debug = true;
function ShowDebugMessage(message) {
if (debug) {
alert(message);
}
}
So when you've declared variable debug which is set to true - all ShowDebugMessage() calls would call alert() as well. So just use it in a code and forget about in place conditions like ifdef or manual commenting of the debug output lines.
For custom projects without any specific overridden console.
I would recommend using: https://github.com/sunnykgupta/jsLogger , it is authored by me.
Features:
It safely overrides the console.log. Takes care if the console is not available (oh yes, you need to factor that too.)
Stores all logs (even if they are suppressed) for later retrieval.
Handles major console functions like log, warn, error, info.
Is open for modifications and will be updated whenever new suggestions come up.
I'm having problems with getting decent JavaScript error invormation in a Production environment.
When I'm developing I can just attach a debugger and (usually) fix the problem.
When I get the same error in a production environment however at best I see is an error report that looks like this:
Error: Object doesn't support this property or method
Url: SomePage
Line: 42
Char: 13
Which doesn't help me very much - I can't see the rendered page and so I have no idea what line 42 looks like.
Is there any way for me to log the entire rendered page contents whenever an error like this occurs? (So line 42 of the output is the line where the error occured)
While I'm at it, are there any other techniques that I can use to help with getting useful error information from JavaScript (without need to break into the debugger) - failing that is there any way that I can structure my JavaScript slightly differently to help getting decent debug information?
I'm predominantly interested in IE - this is the browser that tends to cause me most problems.
I don't think you'll be able to get the exact original HTML source of the page back in all pages and all browsers.
Regarding debugging, you could use a logging library such as log4javascript (disclaimer: I wrote it) and intersperse logging calls in your code. log4javascript enables you to send logging messages back to the server via Ajax.
Unfortunately, IE has by default the most utterly useless error reporting. The script and line number reported in the error are essentially guaranteed to be absolutely wrong. You can, however, install the IE developer tool bar (for IE7 and older, it's built into IE8) from Microsoft, which can help track down the error source.