I used online YUI Compressor for minifying my javascript file... Now i got minified version of it but i lost the source as i uploaded the source javascript file without taking a copy of it...
How can i get source from a minified javascript file?
You will have to work hard, but as a starting point I would recommend you to reformat and reindent the code, there are out there some tools to do it:
JavaScript unpacker and beautifier
JavaScript Beautifier
That as I said, will give you a starting point, you will need to know the code well to rename your variables and functions properly.
The last option would be to consider a rewrite, which if you know exactly what your script is meant to do, can take less time than refactoring the minified source...
And at last but not least I would recommend you to work always with a version control system and do backups often...
Minified JS file is the source code in fact. It's just highly obfuscated.
You can, for example, load this file into Aptana editor and hit ctrl+shift+f to format the source. Or use any other source code formater.
You will get your code structure back, but the variable/function/property names are lost forever.
Hard lesson :)
I've used both the aforementioned
JavaScript unpacker and beautifier
JavaScript Beautifier
but i find the built-in Chrome Pretty print function in the Developer Tools to have been the the most consistent.
it's under the Scripts tab, in the icon menu alongside Pause on debug, Show/hide console, and Window docking
Here is an example where the referenced file is a minified file and automagically transformed into something legible:
http://prettydiff.com/?m=beautify&s=http://prettydiff.com/prettydiff.js
Related
Today I learned that it is possible to include source maps directly into your minified JavaScript file instead of having them in a separate example.min.map file. I wonder: why would anybody want to do something like that?
The benefit of having source maps is clear to me: one can for example debug errors with the original, non-compressed source files while running the minified files. The benefit of minimization is also clear: the size of source files is greatly reduced, making it quicker for browsers to download.
So why on Earth I would want to include the source maps into the minified file, given that the maps have size even greater than the minified code itself?
I searched around and the only reason I could see that people inline source maps is for use in development. Inlined source maps should not be used in production.
The rational for inlining the source maps with your minified files is that the browser is parsing the exact same JavaScript in development and production. Some minifiers like Closure Compiler do more than 'just' minify the code. Using the advanced options it can also do things like: dead code removal, function inlining, or aggressive variable renaming. This makes the minified code (potentially) functionally different than the source file.
This could still be done by referencing external source map files of course, but some people seem to prefer inlining for their build process.
If you are remote debugging Chrome on an android device, the Chrome debugger cannot just access any file it wants on the device and that includes separate map files. If you include them inline you don't have this issue.
JS bundling tools like Browserify or Webpack will bundle all your .js files input one or several bundles, even in developing mode. So in this case, adding inline source map to generated bundles is the easiest way to help debugging without bringing extra files.
In some situations you might want to include inline sourcemaps into evaluated code. E.g you have a coffeescript input field and you want to enable debbuging the code in coffeescript. There is a stackoverflow question about source maps in evaluated code:
Getting source maps working with evaluated code
You could include #sourceURL in your comments to specify a URL of your eval code and load a map file (see page 8 of SourceMap Spec 3). But it is not always possible to write files to some location.
If you're developing a browser extension, inline-source-map is the only option for debugging since extension itself can't access the sourcemap files -- even if it's possible you have to specify all of your sourcemap files inside the manifest.json(config file for browser extensions).
cheap-module-source-map is much better for a production build.
inline-source-map is used to make quick and dirty builds when testing
The use case (for me) is non-browser environments where source maps are not supported (or very much at all, hence the need for webpack.)
Or another way to put it, webpack without the web.
Recently, I found a chrome extension Session Buddy. I want to study the js code of this extension. But the variables in the css and js file constructed only by l and I. The code is unreadable.
So I Google to find some tools change the js code unreadable. but failed.
I want to know Which tools can do this.
and I want to know if there is a tools can guess the origin file (some popular js library)?
The code was most likely minified (which decreases the file size, as well as makes it unreadable). You can use this site to minify your code: http://dean.edwards.name/packer/
You can check the Base62 Encode option to obfuscate the code further.
In order to make minified code more readable, use a Javascript beautifier: http://jsbeautifier.org/
Many developers want to protect their work and use "code obfuscators" to make the code unreadable.
Google for "javascript deobfuscate" to get a list of tools that can revert (some) of the damage. jsbeautifier is one of them.
The documentation for tinymce notes that one can compress all the javascript and components (which I assume includes plugins) into a single file. They do note reasons why one might not want to that as well.
Compressing into a static file
It's also possible to simply concatenate the necessary components and some boilerplate code into a single .js file. However you will always have to recreate this file if you want to use other TinyMCE plugins, or you upgrade TinyMCE. You will also probably want to configure your webserver to compress javascript files.
But assuming one actually did want to do it, how does one actually go about it? Build.xml does does not provide an appropriate task it seems. At least when I tried it the plugins did not seem to be included when I loaded tiny_mce.js.
There are some really excellent command line tools for this, but you can also do this easily with just a text editor. The simplest way is to just open each file, copy the contents, and paste the contents into a single JS file ("everything-all-together.js", say). You'll need to make sure you paste the files into the single file in the same order you would've put the script tags into the HTML doc. Once you have all the files all together, you can use tools like JSXMin, YUI Compressor, or Google Closure. There are also some tools online that do this, like http://www.minifyjavascript.com/. You can paste in the uncompressed JS and copy back out the compressed JS. This makes the build process really cumbersome, but if you just need to do this once, that will get you there.
The best way to do this is to do it as a build step for the site. That means when you make changes to the JS files, you rebuild the compressed JS file to include the changes as well. This can be a cumbersome step if you're iterating quickly and changing files over and over again. You don't want to have to rebuild the compressed file with each save. You can solve this by setting up development and production modes of the site. When being loaded in development mode, the JS files aren't grouped together. When all the necessary changes are made, you'd rerun the build step to generate the single compressed JS file. To do the minification from the command line, you'd probably want to use Google Closure: https://developers.google.com/closure/compiler/. If you download the compiler app, you can do the following:
java -jar compiler.jar some-file.js some-other-file.js > compiled.js
That will generate a file called compiled.js that includes the contents of some-file.js and some-other-file.js in a minified format. You can specify as many files to compile as you need to. Actually, I'm selling Closure a bit short to say it's just minified. It's also extremely optimized code. Pretty much every site should be doing this to all of there JS all the time unless they're already doing something better.
I hope I'm getting you (and the tinymce docs) right, but this sounds a lot like combining JavaScript files on the server side. This means taking the contents of all of your JS files, putting them into one file and returning that one to the client.
Why would you do that? Well, this should be obvious, but.. you reduce the number of HTTP requests to your server, which is always a good thing.
How do you do that? There are many solutions out there for all server-side languages and frameworks, I suggest doing a Google search for "[your language] javascript minifier" or something similar.
Hope this helps.
Is there something like Compass but for javascript? I'm interested in a tool where it will take the main js files and all the other files that are included and compress it to a new js file with all the code on 1 line as soon as you save your changes in whatever file you are working.
Compass includes that functionality. For instance, I use bootstrap.js for one of my projects. I watch the file with Compass and have it minify the file into bootstrap-ck.js, which is the file I refer to in my production code.
I've attached an image which should show you the details. Notice that you can do imports just as you would with Sass or Less.
You'll also be able to have it check the code through JSHint or JSLint. If you're having issues, you can check the Compass documentation or open your config.rb file to see the Compass details for that particular project.
Hope that helps.
You're looking for a Javascript minifier. There are a whole bunch of them to choose from. Try this one or this one, or google for "javascript minifier" for more.
Note that in addition to simply putting all the code on one line, these tools also rename your variables and functions to shorter names, and do a few other tricks to make the code as tiny as possible. The end result should be functionally identical to your original code, but it won't be exactly the same as the code you wrote.
You have a tool from yahoo
http://developer.yahoo.com/yui/compressor/
And you also have a .net tool (if you're working with .net) for this compressor
http://yuicompressor.codeplex.com/
Another recommendation would be UglifyJS
I've inherited an legacy project with tons of javascript files all over the place...
Is there a way to find which of those files are used inside pages?
Thanks in advance.
Use a debugging tool like YSlow!
http://developer.yahoo.com/yslow/
Such tools will usually point out redundant files and code.
You can inspect the website logs of past, say, one month, and locate all *.js files requested by browsers. The log might contain referrer page which makes things easier.
Something that I do very often for .asp files: find a good text editor that allows you to find text inside files/folders. Visual Studio .NET does an excellent job but I've tried and had success with Notepad++ too. Find all files that contain .js. If your text editor provides regular expressions support for searching (the aforementioned products do) this makes things even better. The regexp I use in VS is \.asp> (dot asp followed by a word boundary). The search results are often displayed in a window from where you can copy every thing and do some manual processing via more regex operations or copy the data to an excel file.
Macromedia Dreamweaver does an acceptable job if your website has some structure in it. There is a "Find broken links" command in Dreamweaver that generates a side report called "Orphaned files". The orphaned files report can tell you which js files are not referenced by any page. Then you can run the Dreamweaver's "Find" command (find in entire local website/find in folder) to double check each file one by one. I've tried that too. One thing to note is that Dreamweaver might not be able to detect cycles. E.g. if a file foo.js is used by bar.asp but bar.asp itself is not referenced by any other page, Dreamweaver will flag bar.asp as orphan but not foo.js. The recent version of Dreamweaver might do a better job.
You could create a script in a general purpose scripting language that runs through every html file in your project, checking their script tags. Or you could just do it manually, which may or may not save you some time depending on the size of your project.