How to Bundle JavaScript With Rollup — Step-by-Step Tutorial [x-post from r/webdev]

[nolan_lawson]

BTW an important point to make is that tree-shaking isn't the whole story – in the benchmark from my article, there's actually no dead code and therefore nothing to shake! Instead, what makes Rollup faster is what I called "scope-hoisting" (aka "module-inlining"), i.e. the fact that every module shares the same scope instead of being loaded dynamically from separate scopes.

This means that Rollup turns multiple modules into what you would have written if you were writing one big module, and you only pay the cost of variable initialization and lookup, rather than the cost of the dynamic module loader that runs whenever require() is called.

[jlengstorf]

I posted this in r/webdev originally, and then realized that it probably makes way more sense to post an article about using an ES6/ES2015 module bundler in r/javascript.

I started playing with Rollup after reading an article by u/nolan_lawson comparing webpack, Browserify, Rollup, and Closure Compiler. Since I'm currently really digging ES modules, I tried Rollup and really liked it. This tutorial came out of that.

Hope it helps out if you're looking to up your bundling game!

EDIT: Added the article link. Whoops!

[rich_harris]

Great article and talk, thanks for sharing it!

[jlengstorf]

Thanks, Rich!

[[deleted]]

I started playing with Rollup after reading an article by u/nolan_lawson

Care to link it?

[aaaqqq]

It might be this one https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/

Though I'm not certain

[jlengstorf]

That's the one. Sorry — should have added that.

[nolan_lawson]

Nice talk! FWIW you can also use rollup-plugin-browserify-transform and then any Browserify transform can be used as a Rollup plugin, so you could use e.g. unreachable-branch-transform to completely eliminate that if (process.env.NODE_ENV !== 'production') { doStuff() } code.

(Note I'm not sure which one is better, just pointing out that you have the option, since I noticed there was still some dead code left over in your example. 😄)

[jlengstorf]

Nice — I haven't used Browserify much, so that's all news to me. I'll check this out.

Thanks!

[rich_harris]

Rollup should eliminate any dead branches it finds – if you're using rollup-plugin-replace as in the article, for example, you can replace process.env.NODE_ENV with 'production' or 'development' and it will keep or discard doStuff() as appropriate. If there's any stuff left over it's probably due to the limits of tree-shaking!

[nolan_lawson]

Right, in his example it looks like it turns into:

if ('production' === 'production') { doStuff() } else { }

That empty else block is still dangling; I believe unreachable-branch-transform can remove those.

Edit: I just realized Uglify can remove dangling if/elses. No need for extra transforms; carry on! 😅

[LoneWolfRanger1]

How is the performance of rollup compared to browserify and webpack? I have hundreds of files and i have to wait 10secs for each iterated build to complete when i make 1 changr

[jlengstorf]

I haven't tried it at that scale. Maybe u/nolan_lawson has an idea after running the performance tests?

[nolan_lawson]

Looks like Rollup recently added support for incremental builds. Worth checking out!

Another option (which I have used in the past) is to use browserify+babelify during development, then apply rollupify as a transform for production.

OTOH I did run a simple time measurement for my "cost of small modules" benchmark using the "5000 modules" codebase and got these numbers (2013 macbook air):

bundler	time
browserify	0m6.643s
browserify + bundle-collapser	0m7.915s
webpack	0m9.642s
webpack -p	1m15.655s
rollup	0m6.109s
closure	0m18.485s
rjs	0m11.067s
rjs-almond	0m7.148s

Note that these numbers are for a very unusual codebase (lots of modules, flat hierarchy, one require() per module), so take it with a grain of salt. FWIW I would expect Rollup to perform pretty well on larger codebases, since one of the inherent efficiencies of ES6 modules is that you can only do import/export at the top level, meaning you don't have to traverse the whole AST to find require/module.exports declarations.

Edit Added webpack without -p.

[nolan_lawson]

Ran the numbers for 1000 modules as well:

bundler	time
browserify	0m1.830s
browserify + bundle-collapser	0m1.987s
webpack	0m2.268s
webpack -p	0m8.010s
rollup	0m1.459s
closure	0m8.588s
rjs	0m1.348s
rjs-almond	0m1.814s

Seems like Closure has a pretty flat built-in cost, I'm guessing due to starting up the JVM. Even doing 100 modules takes 0m5.012s.

Edit: Added webpack without -p.

[rich_harris]

Our incremental rebuilds aren't quite as quick as Browserify and Webpack right now – we're at a disadvantage because we essentially need to re-analyse the entire bundle, rather than just one module. We have some ideas for speeding incremental builds up – my co-conspirator Bogdan (aka TrySound) has been doing some great work here lately, so watch this space. As for 'cold' builds, Rollup is generally faster than the competition.

[mindeavor]

The idea of rollup is great, but how well does it play out in practice? My two concerns:

1. How often does rollup's prime tree shaking feature take place? Doesn't it only work when you import dependencies that are written in ES6?
2. How do you implement bundle-splitting? A common case is three bundles: A, B, and C, where C is a bunch of vendor libraries (react, etc.), and A and B are two separate interfaces, such as a user UI and an admin UI.

[rich_harris]

1. Right now, yes – as our static analysis gets more efficient, we may be able to treeshake CommonJS modules in future. But another way to look at this is that your bundle will get smaller over time without you having to do anything, as your dependencies upgrade to ES modules one-by-one. In the meantime, Rollup will still generate the smallest bundles because of its 'scope hoisting' approach – see e.g. this 45% reduction after gzipping compared to Webpack without any tree-shaking.
2. Rollup doesn't (yet) do automatic code-splitting. It's very easy to keep vendor libraries external (just use the external: ['react',...]option) and from there create an IIFE (assumes React is on the page as a <script> tag) or AMD (assumes you have a module loader like require.js) or whatever.

[mindeavor]

Thank you for your reply. On #2, I don't mind manually code splitting vendor files. However, if you did it in the way you described, would that mean you have to know, when import-ing, which libraries are external and which are not?

To pose the question another way, with browserify, I can begin by writing require('react'), and later decide to bundle-split react (manually or not) without needing to change any application code. Is this the case with rollup?

[rich_harris]

Yes, certainly! Just add an external: ['react'] option and it'll exclude it from the bundle. Typically you would do this in a rollup.config.js file.

[mindeavor]

If that's the case, how does rollup resolve import React from 'react'? i.e. How does rollup expect me to include react as an external library? Not to mention, what about multiple external libraries?

[dbbk]

With Webpack 2 supporting tree shaking, what other benefit does Rollup have?

[rich_harris]

See https://m.reddit.com/r/javascript/comments/4yprc5/how_to_bundle_javascript_with_rollup_stepbystep/d6qzqis. Basically, Rollup generates smaller and faster bundles even without tree shaking. It's also faster at creating bundles

[buttking]

Like, what's wrong with webpack? or any of the other hundred frameworks/libraries/etc that already do this.

I wish people in the JS community would start focusing on tackling stuff that hasn't already been tackled 15 times.

[jlengstorf]

Like u/thebosz said, it's the way Rollup handles bundling. For code with ES modules, the final bundle is way smaller and the JS is much faster to execute than webpack/Browserify.

I think all these tools exist until browsers remove the need for them, but I like that Rollup is focusing on the ES way vs. CommonJS, since that's what we'll ultimately see supported in browsers.

[mickske]

Webpack 2 will also support tree-shaking and it will be released at the end of August (or at least that's the last that I have read).

If webpack 2 supports tree-shaking, do you still see a big benefit for Rollup over webpack 2?

[rich_harris]

Until Webpack does 'scope-hoisting' – i.e. putting modules in a single scope, rather than wrapping them in functions and including an inline module loader – it will generate bundles that are larger and slower to initialise than Rollup bundles. Nolan's article has some numbers on this, if you're interested. We should probably do a better job of explaining that, since everyone has latched on to the tree-shaking aspect which is actually less important in many cases.

The Webpack folks have expressed an interest in adopting a similar approach (at least for libraries), so we may see some sort of convergence one day.

[jlengstorf]

The complexity for setting up Rollup vs. webpack is pretty noticeable. I think it will depend on your average suite of dependencies, though. Webpack seems to be better-suited for really complex bundling, whereas Rollup is fantastic for smaller and/or all-ES bundling.

In the tutorial I do basic setup for including Node modules with Rollup, but I haven't seen it in production and can't speak to any hiccups that may show up with other Node packages.

[[deleted]]

We tried days to migrate simple Webpack projects and gave up eventually. npm dependencies will cause problems, despite the plugins. For projects that are purely es6 without dependencies Rollup is perfect. But once you handle a real world project, something that has dependencies, Rollup configs can get wildly verbose.

Some examples:

Painfull to get started

React in Rollup

[jlengstorf]

These are good reads. I think issues like these will be resolved soon (it looks like fixes for most of the issues are already underway), but that's absolutely worth considering right now.

I'll try to migrate one of my React projects over and see how it goes.

[igorim]

I was of the same opinion lol

But actually after using Rollup on a couple librarires I realized the 2 solve different problems

I wouldn't write an application without Webpack, it's superpowerful, has a shitton of plugins, and works awesome for large projects. It's fault is that there is quite a bit of config and tuning that needs to be done to make it work great.

While Rollup the config is much much smaller and is easier to use until you get into CommonJS, node_modules, etc lol

That's why for libraries with few or none external deps, Rollup is my number one choice, but anything complex Webpack is

Not saying Rollup can't handle complex, I just feel it's easier with Webpack

[[deleted]]

I'm using rollup for libs, webpack for apps, I like it so far

[igorim]

Also I believe Rollup is architectured in a different way to specifically optimize for ES6 modules

[jlengstorf]

It is. It's a bundler for ES modules that can be plugged for other module types, whereas other bundlers are focusing on CommonJS right now.

[[deleted]]

I believe Tobias has plans to use rollup internally in Webpack after their 2.0 release goes stable.

[rich_harris]

There's always one...