rollup

What is rollup?

Rollup is a module bundler for JavaScript which compiles small pieces of code into something larger and more complex, such as a library or application. It is optimized for bundling JavaScript files to use in a browser, and it is also capable of transforming code using plugins.

What are rollup's main functionalities?

Bundling Modules

Rollup can bundle multiple JavaScript modules into a single file. The above code demonstrates how to create a bundle from an entry point file 'src/main.js' and output it as an immediately-invoked function expression (IIFE) to 'bundle.js'.

import rollup from 'rollup';

async function build() {
  const bundle = await rollup.rollup({
    input: 'src/main.js'
  });

  await bundle.write({
    file: 'bundle.js',
    format: 'iife',
    name: 'MyModule'
  });
}

build();

Tree-shaking

Rollup includes a feature called 'tree-shaking' which removes unused code from the final bundle. This helps in reducing the size of the bundle and improving load times.

import { rollup } from 'rollup';

rollup({
  input: 'src/index.js',
  treeshake: true // Tree-shaking is enabled by default
}).then(bundle => {
  // Code to write the bundle
});

Plugin System

Rollup supports a wide range of plugins that can transform the code, add functionality, or integrate with other build tools. The code sample shows how to use the JSON plugin to import JSON files as modules.

import { rollup } from 'rollup';
import json from '@rollup/plugin-json';

rollup({
  input: 'src/index.js',
  plugins: [json()]
}).then(bundle => {
  // Code to write the bundle
});

Other packages similar to rollup

webpack

Webpack is a powerful module bundler that can handle not only JavaScript but also assets like images, fonts, and stylesheets. It has a larger ecosystem and more configuration options compared to Rollup, making it more suitable for complex applications.

parcel

Parcel is a web application bundler that offers a zero-configuration experience. It is known for its fast build times and out-of-the-box support for various file types. Parcel is easier to set up than Rollup and Webpack but may offer less fine-grained control.

browserify

Browserify allows you to use `require('modules')` in the browser by bundling up all of your dependencies. It is one of the earlier bundlers and is focused on simplicity and ease of use, but it doesn't have built-in tree-shaking like Rollup.

README

rollup

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

I roll up, I roll up, I roll up –Wiz Khalifa

This is an early stage project under active development. If you find a bug, please raise an issue!.

A next-generation ES6 module bundler

Right now, you have a few different options if you want to create a bundle out of your ES6 modules:

• The best option, in terms of performance, size of the resulting bundle, and accurate representation of ES6 module semantics, is to use esperanto. It's used by ractive.js, moment.js, Facebook's immutable.js, the jQuery Foundation's pointer events polyfill, Ember CLI and a bunch of other libraries and apps
• You could use jspm, which combines a module bundler with a loader and a package manager
• Or you could use browserify or webpack, transpiling your modules into CommonJS along the way

But there's a flaw in how these systems work. Pretend it's the future, and lodash is available as an ES6 module, and you want to use a single helper function from it:

// app.js
import { pluck } from 'lodash';

With that single import statement, you've just caused the whole of lodash to be included in your bundle, even though you only need to use a tiny fraction of the code therein.

If you're using esperanto, that's not totally disastrous, because a sufficiently good minifier will be able to determine through static analysis that most of the code will never run, and so remove it. But there are lots of situations where static analysis fails, and unused code will continue to clutter up your bundle.

If you're using any of the other tools, static analysis won't be able to even begin to determine which of lodash's exports aren't used by your app (AFAIK! please correct me if I'm wrong).

The current solution is not future-proof

I picked lodash because it does offer one solution to this problem: modular builds. Today, in your CommonJS modules, you can do this:

var pluck = require( 'lodash/collection/pluck' );

This is not the answer. Using a folder structure to define an interface is a bad idea - it makes it harder to guarantee backwards compatibility, it imposes awkward constraints on library authors, and it allows developers to do this sort of thing:

var cheekyHack = require( 'undocumented/private/module' );

Sure enough, you won't be able to do this with ES6 modules.

A better approach?

This project is an attempt to prove a different idea: ES6 modules should define their interface through a single file (which, by convention, is currently exposed as the jsnext:main field in your package.json file), like so...

// snippet from future-lodash.js
export { partition } from './src/collection/partition';
export { pluck } from './src/collection/pluck';
export { reduce } from './src/collection/reduce';
/* ...and so on... */

...and ES6 bundlers should handle importing in a much more granular fashion. Rather than importing an entire module, an intelligent bundler should be able to reason like so:

• I need to import pluck from future-lodash.js
• According to future-lodash.js, the definition of pluck can be found in lodash/src/collection/pluck.js
• It seems that pluck depends on map and property, which are in... these files
• ...
• Right, I've found all the function definitions I need. I can just include those in my bundle and disregard the rest

In other words, the 'tree-shaking' approach of throwing everything in then removing the bits you don't need is all wrong - instead, we should be selective about what we include in the first place.

This is not a trivial task. There are almost certainly a great many complex edge cases. Perhaps it's not possible. But I intend to find out.

Goals

• Maximally efficient bundling
• Ease of use
• Flexible output - CommonJS, AMD, UMD, globals, ES6, System etc
• Speed
• Character-accurate sourcemaps
• Eventually, port the functionality to esperanto

Secondary goals

• Support for legacy module formats
• Respect for original formatting and code comments

API

The example below is aspirational. It isn't yet implemented - it exists in the name of README driven development.

rollup.rollup({
  // The bundle's starting point
  entry: 'app.js',

  // Any external modules you don't want to include
  // in the bundle (includes node built-ins)
  external: [ 'path', 'fs', 'some-other-lib' ]
}).then( function ( bundle ) {
  // generate code and a sourcemap
  const { code, map } = bundle.generate({
    // output format - 'amd', 'cjs', 'es6', 'iife', 'umd'
    format: 'amd',

    // exports - 'auto', 'none', 'default', 'named'
    exports: 'auto',

    // amd/umd options
    moduleId: 'my-library',

    // umd options
    moduleName: 'MyLibrary', // necessary if the bundle has exports
    globals: {
      backbone: 'Backbone'
    }
  });

  fs.writeFileSync( 'bundle.js', code + '\n//# sourceMappingURL=bundle.js.map' );
  fs.writeFileSync( 'bundle.js.map', map.toString() );

  // possible convenience method
  bundle.write({
    dest: 'bundle.js', // also writes sourcemap
    format: 'amd'
  });
});

The duplication (rollup.rollup) is intentional. You have to say it like you're in the circus, otherwise it won't work.

License

Not that there's any code here at the time of writing, but this project is released under the MIT license.

Changelog

0.8.1

• Anonymous functions that are exported as default are converted to named function declarations for correct hoisting, rather than being bound to functions (#29)
• Automatically-generated default export names are deconflicted with local definitions (#29)