zhanzhenzhenjs-bundler
Bundles the specified file and all "required" files into one. Similar to browserify, but no Node built-in module shims, no source mapping. So it's lightweight.
Because it doesn't provide shims, please only bundle "browser" or "neutral" packages that don't depend on Node built-in modules.
Synopsis
bundle [-c:<file-type> <command>]... [-d <require-string>]... [-n <negate-pattern>]... [-i] <file>
bundle (-v | --version)Examples
bundle example.jsThis will send the bundled output to stdout.
To output to a file:
bundle example.js > bundle.jsTo bundle CoffeeScript:
bundle -c:coffee 'coffee -bcs' example.coffee(Note: -c is for Node 0.12 or higher.)
To bundle a JavaScript file that "requires" CoffeeScript files, that is, the .js file has require("coffee-script/register"):
bundle -c:coffee 'coffee -bcs' -d 'coffee-script/register' example.js-d means "dummy". It will bundle an empty module rather than the real "coffee-script/register" module.
Sometimes you want to prevent something from being bundled (for instance, it will never be run on browser). There are 3 ways to do that: dummy, the browser field, or a module. prefix.
Browser field specification:
https://gist.github.com/defunctzombie/4339901
The module. prefix is just a trick:
if (environment === "server") {
var abc = module.require("./abc");
}Note that dummies apply only to require strings, and only to external package modules. Another difference is that a dummy is treated as a module so "require" doesn't throw an error, but if you use module. prefix and your if condition doesn't prevent the inner code running, then module.require will throw an error.
To add informative data (i.e. raw file's relative path to the working directory) to the output:
bundle -i example.jsThis is useful in debugging. But for security, we recommend you use this option only for testing, or use a minifier to remove JavaScript comments in its downloadable version, because this option discloses the relative paths.
-n is to make sure there're no file or directory matching the pattern in the bundle. Useful for security purposes. For example:
bundle -n '*/server.*' example.jsIf the file example.js contains require("./server.main") and there's a file server.main.js, then it will result in an error so that it won't build a bundle containing the sensitive server-side file, which is often a mistake. You can correct your code and bundle again.
Supported patterns:
<segment><segment>**/<segment>*/<segment>*
<segment> can contain "/" (not trailing or leading) but can't contain "*".
If a directory matches the pattern, then it will also affect all its files and subdirectories, recursively.
The patterns don't affect external files (namely, the files under node_modules). The pattern foo* means the actual relative path (not the require string) begins with foo. The pattern foo.js means the actual relative path is foo.js. Note: Relative path foo.js matches pattern */foo.js because the path can be treated as "./foo.js".
Also note: If your pattern contains *, then it must be enclosed with single or double quotes, otherwise it won't be sent to the program correctly.
For negation error the process exits with exit code 64. For other error the exit code is 1.
To print the version:
bundle -vOutput
The 18-digit number 674497323404793172 in the output is just an identifier of js-bundler related things. When you search for "file-674497323404793172" (representing the start position of every file) while debugging in browser, the results are very accurate. Here's part of an example output:
// *****
// ***** sss.coffee file-674497323404793172
// ***** (((
// Generated by CoffeeScript 1.9.1
(function() {
return console.log("inner");
})();
console.log("done");
// ***** ))) file end