I have many js files, with some naming convention. If there any tool that concatenate all this files in one, so I don't need to include them all separately ?
You could look at using a JS Minifier, like:
http://code.google.com/p/minify/
http://code.google.com/closure/compiler/
http://www.crockford.com/javascript/jsmin.html
Something like:
$> cat file1.js file2.js ... > allfiles.js
?
In bash:
for file in `ls *js` ; do cat "$file" >> outputscript.js; echo >> "$file"; done;
You might find some helpful information here. Several answers advocate creating multiple javascript files during development, just so developers don't go crazy scrolling through thousands of lines of code. Those files are then merged during deployment -- several approaches are suggested. Several respondents also advocate using minification, which can reduce the size of the resulting mega-file.
In addition to the straightforward answers like using cat or a minifier, you can also use Sprockets, which is a JavaScript build system written in Ruby. Prototype JS uses Sprockets (in fact it Sprockets was written for Prototype).
Related
I would like to merge 2.5 million smallish xml files from a directory tree into one large json file, and I was trying to do this using bash using find and the xml2json utility.
I'm pretty new to bash and haven't done anything very complicated with it. My intuition is something like following (but this is a long way from working):
find . -exec xml2json {} ; cat >> merged.json
Problem #1: I can't figure out how to use the xml2json utility with -exec.
find . -exec /usr/bin/xml2json < {}
doesn't work (seems like it's waiting for more input?). Neither does
find . -exec /usr/bin/xml2json {}
How do I get this working?
Problem #2: What is the most efficient way to concatenate the files? Obviously just using cat isn't going to create a well-formed json file, but can I just concatenate in brackets at the start and end and commas in between? Or should I use something like jq's -s? Do I need to stream it or parallelize it?
If it turns out bash is bad for this, efficient alternatives in JavaScript, R, or Python would also be useful. Thanks.
I have three files containing js classes:
A.js
B.js
C.js
I'm trying to concatenate them to get something like:
var Module = (function (scope) {
// content of concatenation (ABC.js)
})(scope);
For now I'm using https://www.npmjs.com/package/grunt-contrib-concat to concatenate, I saw https://www.npmjs.com/package/grunt-wrap, it seems to be abandonned but look like what I want.
Someone has an idea to achieve it without using grunt-concat?
PS: I want to keep a *.map file for debug purpose
Are you looking for the banner/footer of https://github.com/gruntjs/grunt-contrib-concat?
Or this kind of concatenation with 2 files for intro and outro? I'm trying out Grunt and need a simple way to concatenate my modules
I think you might want to have a look at Browserify and Browserify-shim. It's an excellent way of scoping your dependencies without polluting the global namespace. It's works well with grunt and gulp and supports sourcemaps too.
Has any one had any success with this?
I think it's more or less an unsolved problem:
https://github.com/jashkenas/coffee-script/issues/2779 . Last meanigingful comment was from jwalton, a month ago.
Still, it doesn't seem rocket science to add support for it, so it will probably come soon.
Michael Ficarra (creator of CoffeeScript Redux) suggested using https://github.com/michaelficarra/commonjs-everywhere .
Two caveats:
It only works for bundling CommonJS modules.
It uses CoffeeScript Redux, which is still in beta (although working quite well it seems), and not 100% compatible with original CoffeeScript compiler.
So this does not work for what you ask for specifically, "concatenation".
Added April 14
You might have luck with these: combine-source-map and/or generate-sourcemap, both by same author.
Added April 26
This looks really simple: https://npmjs.org/package/mapcat . You just have to feed it the individual source map files generated by the coffee compiler.
Added May 16
Mariusz Nowak has just released webmake-coffee. Like CommonJS Everywhere, it requires code to be organized as CommonJS modules. Unlike CommonJS everywhere, it uses regular CoffeeScript.
It also seems the Grunt Coffee-Script plugin has had source-map support for concatenated files for quite a while (two months), effectively proving my original answer to be incorrect.
The upcoming version 2.0 of Snockets will have support for it too.
I ended up going with browserify using coffeeify as the transform option, and enabling browserify's debug option. I bundle up the app on each request for my main.js file, and any runtime errors show up in my original source with pretty decent accuracy.
Sure beats mapping runtime errors in the concatenated/compiled js back to the coffee source with my eyeballs!
I needed to annotate AngularJS code before minification, but grunt-ng-annotate didn't accept input source maps, thus I would not be able to use maps generated by the CoffeeScript compiler.
Apparently, with gulp-sourcemaps this is not an issue:
var gulp = require('gulp');
var $ = require('gulp-load-plugins')(); // loading gulp plugins lazily
// remember to include them in the package.json
gulp.task('appJS', function() {
// concatenate compiled .coffee files and js files into build/app.js
gulp.src(['./app/**/*.js','./app/**/*.coffee'])
.pipe($.sourcemaps.init())
.pipe($['if'](/[.]coffee$/, $.coffee({bare: true}).on('error', $.util.log)))
.pipe($.concat('app.js'))
.pipe($.ngAnnotate())
.pipe($.uglify())
.pipe($.sourcemaps.write())
.pipe(gulp.dest('./build'))
});
The same approach works in other situations, too. In my case, this is the only approach that worked.
I have written a grunt task that does this flawless. Check it out
I want to use the google closure compiler on the javascript source we're using.
In development mode we tend to break functionality to lots of files but for production would like to have them combined into modules.
When calling the compiler I can give it a list of files to include for compilation, but the output of that shows that the compiler did not save the order of the files list.
I searched about it and found that I can use goog.provide/good.require in order to control the dependencies between the different js files.
The problem with that is that it adds code to my js which I just don't need or want, for example:
goog.provide("mainFile")
will add this:
var mainFile = {};
to the compiled js file, something that I don't want.
We're not using the google closure library at all, all I want to use is the compiler.
Is there a way to tell the compiler the order of the files without including more "closure library" functionality which I have no need for?
I can of course create a tool of my own which will first take all the files, combine them into one which will then be the input of the compiler, but I would prefer to void that if it can be done by the compiler itself.
Edit
The goal is to be able to produce modules like the answer in this thread: Using the --module option in Closure Compiler to create multiple output files
And so I want to add to that the ability to control which files go into which module while also having control on their order.
For now I don't use wildcards, but I plan to do so in the future (if it's possible).
simply "cat file1.js file2.js > combined.js && compile..." is fine, but in our case it's a bit more complicated and we'll have to write a program/script that does that based on some logic.
If we can somehow tell the compiler the order of the files in advanced it might just save the time of implementing such a program.
Thanks.
Closure-compiler's ability to create multiple output files provides a powerful tool to separate input files into distinct output chunks. It is designed such that different chunks can be loaded at differing times depending on the features required. There are multiple compiler flags pertaining to chunks.
Each use of the --chunk flag describes an output file and it's dependencies. Each chunk flag follows the following syntax:
--js inputfile.js
--chunk name:num_files:dependency
The resulting output file will be name.js and includes the files specified by the preceding --js flag(s).
The dependency option is what you will be most interested in. It specifies what the parent chunk is. The chunk options must describe a valid dependency tree (you must have a base chunk).
Here's an example:
--js commonfunctions.js
--chunk common:1
--js page1functions.js
--js page1events.js
--chunk page1:2:common
--js page2function.js
--chunk page2:1:common
--js page1addons.js
--chunk page1addons:1:page1
In this case, you are telling the compiler that the page1 and page2 chunks depend on the common chunk and that the page1addons chunk depends on the page1 chunk.
Keep in mind that the compiler can and does move code from one chunk into other chunk output files if it determines that it is only used by that chunk.
None of this requires closure-library or the use of goog.require/provide calls nor does it add any code to your output. If you want the compiler to determine dependencies automatically or to be able to manage those dependencies for you, you'll need to use a module format such as CommonJS, ES2015 modules or goog.require/provide/module calls.
Update Note: Prior to the 20180610 version, the chunk flags were named module. They were renamed to reduce confusion with proper JS modules. The answer has been updated to reflect the new names.
Update Note 2: There is now a utility to automatically calculate and generate these flags for you: https://github.com/ChadKillingsworth/closure-calculate-chunks
You can also set the output path, for example with:
--module_output_path_prefix ./public/js/
See also:
Using the --module option in Closure Compiler to create multiple output files
I have a backbone app with over 50 small JavaScript files. Now I want to put all those in one single file, but it should still be readable, so:
Is there a tool for combining JavaScript files without minifying or uglyfying them?
cat (standard on UNIX-like systems).
cat foo.js bar.js > combined.js
You may run into problems if you have any scripts that do not end with a new line while depending on semi-colon insertion for that line.