You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Oskar Segersvärd e8b44a7308 Merge branch 'called-but-unused-import' of github.com:mbostock/rollup into fix-977 8 years ago
.github remove link markdown and squashing bullet point 8 years ago
bin/src Fix --help format description 8 years ago
browser add back removed path methods for browser 9 years ago
src Merge branch 'master' of https://github.com/rollup/rollup 8 years ago
test Merge branch 'called-but-unused-import' of github.com:mbostock/rollup into fix-977 8 years ago
.eslintignore more aggressive linting 9 years ago
.eslintrc linting 8 years ago
.gitattributes Force unix linebreaks 9 years ago
.gitignore only ignore top-level node_modules 9 years ago
.travis.yml put 0.12 back in the build matrix 8 years ago
CHANGELOG.md -> v0.36.3 8 years ago
LICENSE.md add: interop option 8 years ago
README.md Merge pull request #1002 from jlengstorf/docs/tutorial 8 years ago
appveyor.yml put 0.12 back in the build matrix 8 years ago
package.json -> v0.36.3 8 years ago
rollup.config.browser.js oops 8 years ago
rollup.config.cli.js replace require kludge in runRollup.js (#706 - comment) 8 years ago
rollup.config.js support 0.12 8 years ago

README.md

Rollup

build status npm version license dependency status Coverage via Codecov Join the chat at https://gitter.im/rollup/rollup

I roll up, I roll up, I roll up, Shawty I roll up

I roll up, I roll up, I roll upWiz Khalifa

Quickstart

Rollup can be used via a JavaScript API or a Command Line Interface. Install with npm install -g rollup and run rollup --help to get started.

If the command line's not your jam, there's also a step-by-step tutorial video series (with accompanying written walkthrough).

Dive into the wiki when you're ready to learn more about Rollup and ES6 modules.

A next-generation ES6 module bundler

When you're developing software, it's much easier to break your library or application apart into separate pieces that you can work on separately. It's also very likely that you'll have dependencies on third party libraries. The result is lots of small files – but that's bad news for browsers, which get slowed down by having to make many requests. (It's also bad news for Node!)

The solution is to write your code as modules, and use a module bundler to concatenate everything into a single file. Browserify and Webpack are examples of module bundlers.

So far, so good, but there's a problem. When you include a library in your bundle...

var utils = require( 'utils' );

var query = 'Rollup';
utils.ajax( 'https://api.example.com?search=' + query ).then( handleResponse );

...you include the whole library, including lots of code you're not actually using.

ES6 modules solve this problem. Instead of importing the whole of utils, we can just import the ajax function we need:

import { ajax } from 'utils';

var query = 'Rollup';
ajax( 'https://api.example.com?search=' + query ).then( handleResponse );

Rollup statically analyses your code, and your dependencies, and includes the bare minimum in your bundle.

Shouldn't we be writing those utilities as small modules anyway?

Not always, no.

Don't minifiers already do this?

If you minify code with something like UglifyJS (and you should!) then some unused code will be removed:

(function () {
  function foo () {
    console.log( 'this function was included!' );
  }

  function bar () {
    console.log( 'this function was not' );
    baz();
  }

  function baz () {
    console.log( 'neither was this' );
  }

  foo();
})();

A minifier can detect that foo gets called, but that bar doesn't. When we remove bar, it turns out that we can also remove baz.

But because of the limitations of static analysis, and the dynamic nature of JavaScript, it can't do the same thing with code like this:

(function () {
  var obj = {
    foo: function () {
      console.log( 'this method was included!' );
    },

    bar: function () {
      console.log( 'so was this :-(' );
      this.baz();
    },

    baz: function () {
      console.log( 'and this :-(' );
    }
  };

  obj.foo();
})();

Unfortunately, traditional modules – CommonJS and AMD – result in code more like the second example than the first, making them next-to-impossible to optimise. Rather than excluding dead code, we should be including live code (aka 'tree-shaking'). That's only possible with ES6 modules.

Can I use it with my non-ES6 dependencies?

Yes! Rollup can't work its tree-shaking magic on CommonJS modules, but it can convert them to ES6 via plugins.

Can I distribute my package as an ES6 module?

If your package.json has a jsnext:main field, ES6-aware tools like Rollup can import the ES6 version of the package instead of the legacy CommonJS or UMD version. You'll be writing your code in a more future-proof way, and helping to bring an end to the dark days of JavaScript package management. Learn more here.

See rollup-starter-project for inspiration on how to get started.

How does this compare to JSPM/SystemJS?

JSPM is awesome, and it uses Rollup in its builder! In addition to bundling modules, it also combines a repository with a package manager and a client-side module loader. JSPM allows you to use any module format and even develop without a build step, so it's a great choice for creating applications. Stand-alone Rollup doesn't use the complex SystemJS format, making it a better choice for creating libraries.

License

Released under the MIT license.