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
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.
I just finished my website, which I started 2 years ago. I was always trying new things, which sometimes included adding different frameworks or other external JS files.
Now I don't know which of the linked files/lines of JS are unused. Is there a tool which can detect these files and lines of code? It would save me a lot of time.
This answer offers Google's Closure Compiler which, in the process of minifying and concatenating your JavaScript code, can remove "dead code".
Quoting from the documentation for the compilation levels:
Compilation with ADVANCED_OPTIMIZATIONS removes code that is provably unreachable. This is especially useful in combination with large libraries. If you use only a few functions from a large library file, the compiler can remove everything except those functions from its output.
Also see this answer which contains more information on Google's Closure Compiler.
I had this need so I created a tool that detects unused JS on the browser side, not just from the sources, so it can also test third parties scripts.
It works by creating a local proxy on your computer that intercepts JavaScript requests and instruments these files on-the-fly. The tool is than able to detect which parts of the instrumented files have been used by the page, and which don't.
I made it open-source and you can find it here: https://github.com/gmetais/unusedjs.
For this answer, I am not sure whether it's helpful or not. How about trying Sonar. Sonar has a javascript plugin that can check your js code quality and list the code that unused.
I've been looking at a similar task for the past few weeks myself and ended up with the following powershell query:
PS> Get-ChildItem -Path C:\PathToProject\ -Filter *.as?x -Recurse
| select-string -pattern "src=""([^""]*.js)"""
| Select -Expand Matches | Foreach { $_.Groups[1].Value } | select -unique
First it recursively selects all .aspx and .ascx files in our project directory, then finds src attribute values that refer to .js files (presumably those of script elements) and traces distinct values - voila, you have a list of .js files as referenced in your project!
It would be fairly straightforward to adjust the query so that it fits your specific project and its structure. Make sure you don't iterate over outdated files that may include obsolete references. Account for markup discreptancies - could you have used single quotes for attribute values in the past, or left unnecessary whitespace around the "equals" symbol, or both? Could you be including these files programmatically or asynchronously from inside another js files? etc. etc.
In Google Chrome Developer tools, you can now view "Coverage" on the Sources tab to display unused Javascript and CSS by percentage of each file, or even on a line by line basis.
Here's the announcement of the feature in 2017.
Though it is pretty old question, this might help for this type of problem - https://github.com/skpaul/LocateMe
I wrote this to use in my project.
I am not even sure if something like I want is possible, so I am asking you guys to just let me know if anyone did that before. So, my goal is to when I click on "Publish" website in VS2010, to have all javascript files compressed into one, same with css and then in my layout file change the references from all different js and css files to only those two merged ones. Is that doable? Or maybe it's doable but in more manual way?
Of course the goal here is to have only two calls to external files on the website, but when I develop I need to see all files so that I can actually work with it. I guess I could do it manually before each push, but I'd rather have it done automatically using some script or something. I didn't try anything yet, and I am not looking for ready solution, I am just looking to get to know the problem better and maybe some tips.
Thanks a lot!
This is built into ASP.net 4.5. But in the mean time, you should look at the following projects
YUI Compressor
The objective of this project is to compress any Javascript and Cascading Style Sheets to an efficient level that works exactly as the original source, before it was minified.
Cassette
Cassette automatically sorts, concatenates, minifies, caches and versions all your JavaScript, CoffeeScript, CSS, LESS and HTML templates.
RequestReduce
Super Simple Auto Spriting, Minification and Bundling solution
No need to tell RequestReduce where your resources are
Your CSS and Javascript can be anywhere - even on an external host
RequestReduce finds them at runtime automatically
SquishIt
SquishIt lets you squish some JavaScript and CSS. And also some LESS and CoffeeScript.
Combres
.NET library which enables minification, compression, combination, and caching of JavaScript and CSS resources for ASP.NET and ASP.NET MVC web applications. Simply put, it helps your applications rank better with YSlow and PageSpeed.
Chirpy
Mashes, minifies, and validates your javascript, stylesheet, and dotless files. Chirpy can also auto-update T4MVC and other T4 templates.
Scott Hanselman wrote a good overview blog post about this topic a while back.
I voted up the answer that mentioned Cassette but I'll detail that particular choice a little more. Cassette is pretty configurable, but under the most common option, it allows you to reference CSS and Javascript resources through syntax like this:
Bundles.Reference("Scripts/aFolderOfScriptsThatNeedsToLoadFirst", "first");
Bundles.Reference("Scripts/aFolderOfScripts");
Bundles.Reference("Styles/aFolderOfStyles");
You would then render these in your master or layout pages like this:
#Bundles.RenderStylesheets()
#Bundles.RenderScripts("first")
#Bundles.RenderScripts()
During development, your scripts and styles will be included as individual files, and Cassette will try to help you out by detecting changes and trying to make the browser reload those files. This approach is great for debugging into libraries like knockout when they're doing something you don't expect. And, the best part, when you launch the site, you just change the web.config and Cassette will minify and bundle all your files into as few bundles as possible.
You can find more detail in their documentation (which is pretty good though sometimes lags behind development): http://getcassette.net/documentation/getting-started
Have a look at YUI compressor # codeplex.com this could be really helpful.
What I have done before is setup a post-build event, have it run a simple batch file which minimizes your source files. Then if you're in release mode (not in debug mode), you would reference the minimized source files. http://www.west-wind.com/weblog/posts/2007/Jan/19/Detecting-ASPNET-Debug-mode
I haven't heard about publish minification. I think use should choose between dynamical minification like SquishIt or compile time like YuiCompressor or AjaxMinifier.
I prefer compile time. I don't think it's very critical to have to compile time changing files. If you have huge css/js code lines you can choose this action only for release compilation and if it helps publish this files only in needed build cinfigurations.
I don't know if there is any possible way to somehow hook into the functionality from that 'Publish' button/whatever it is, but it's surely possible to have that kind of 'static build process'.
Personally I'm using Apache ANT to script exactly what you've described there. So you're developing on your uncompressed js/html/css files and when you're done, you call like ant build which then minifies, compresses, stripes and publishes your whole web application.
Example script: https://github.com/jAndreas/typeof-NaN-2.0/blob/master/build/build.xml
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.
I've developing JavaScript since many years but have never really thought about the whole testing, developing and building stuff - but I realized it's pretty much necessary. We've just used a Subversion repository with simple release tagging (switching to git soon). As a new bigger pure JavaScript project (using jQuery) is arriving soon, I'd like to optimize the whole process.
I already did some research but never found a good starting tutorial.
It's definetly a good idea to split classes and separate code blocks into several js-files and not a big one (as Prototype or jQuery do it). These js-files must be "build" into a single file. How do I achieve that?
It's pretty much necessary to Unit-test the stuff me and my colleagues are coding. I found the js-test-driver which has an eclipse plugin that seems to be doing his job quite good. If my developer-folder contains all these src- and src-test-files, how do I integrate this in the building process?
For testing, take a look at this: https://stackoverflow.com/questions/32809/javascript-unit-testing
For merging all of your JavaScript into one file you can use something like YUI Compressor. You need to be looking for a minimizer first, compression second. A minimizer just takes the files and merges them together and gets rid of whitespace. A compressor will actually try to optimize the js for you by changing variable names and removing unnecessary code.
As for unit testing I am unsure of how you will want to do that. There are a few unit test libraries out there. A popular tool for testing is Selenium. I don't currently do unit testing so I am out of my element there..
For setting up your code you could always look at using a JavaScript framework like ExtJS or JavaScriptMVC. Those help you with setting up your code in the proper way and also helps focus your team on the proper standards and coding structure while also writing a lot of the code for you so you don't have to re-invent the wheel.
EDIT: Just a quick after thought. Even if you don't want to use a JavaScript framework, I would suggest checking them out, especially ExtJS, just to see how they organize their code and some of the tricks they do to keep it clean.
I'll answer part of your question:
These js-files must be "build" into a
single file.
This is possible only with server side language - in ASP.NET you have built in tools for that, otherwise build your own "merger" server side file and reference that file instead of the actual .js files.
These js-files must be "build" into a single file. How do I achieve that?
Definitely keep your files separate in version control, and only merge them during the build process.
The YUI compressor mentioned elsewhere is a java-based tool that will not only merge but -- of course! -- compress your files for faster download.
If you just want a simple merge of files, a simple Perl or bash-script (or other preferred scripting language) could concatenate multiple .js files into one for release -- just make sure that the build script also updates all HTML in the release to reference only the single page.