Rollup support

[Rich-Harris]

Making a start on #130. Early signs are encouraging — builds are, predictably, smaller and faster.

For webpack users, nothing should change. Internally, a few things are different:

• There are WebpackCompiler and RollupCompiler classes that abstract away the underlying bundler with a common interface, used in dev and build
• Sapper will look to see if there is a rollup directory, and if so create a RollupCompiler for client, server and (optionally) service worker. If not, it falls back to webpack
• Stats munging is handled by the compiler facades
• The dev client is always loaded in dev mode, rather than just when HMR is enabled. Eventually, we'll use that channel to display error overlays etc, rather than just handling HMR logic

Several issues remain:

• Currently, the main client <script> has type="module", because Rollup is generating ESM. This works brilliantly in Chrome, where dynamic import(...) is supported, but not in Firefox where type="module" works fine, but dynamic import causes "SyntaxError: expected expression, got keyword 'import'". It would be wonderful to use native module loaders where available, but we might have to settle for loadz0r for the next few months, unless we can do some cool differential bundling stuff.
• Related to the ESM output — Terser doesn't mangle local names of imports, which means the output is larger than it needs to be (but still signficantly smaller than the webpack output!), and I ran into a bug with Closure Compiler when I tried to use that instead. Maybe I'll try and work on both bugs at some point, but it's low priority since using AMD+loadz0r would work around it.
• I'm not sure if Rollup can be configured to emit named chunk information that would allow those chunks to be preloaded. This isn't a dealbreaker but would be a nice-to-have
• There's currently no way to know which file caused in invalidation, as far as I can see — again, a nice-to-have
• It doesn't currently print a build summary or output errors and warnings

You can see how the config requirements change in sapper-template-rollup — see the new rollup directory, which replaces webpack. No source code changes are required.

[Rich-Harris]

Oh, and another problem/TODO — output filenames aren't hashed, which causes the usual caching nonsense with service workers. We could use rollup-plugin-hash but then we wouldn't be able to reliably determine where the entry point was in the output client directory.

[Conduitry]

I don't know whether this will help, but Terser does have a module: true option that will (among other things) cause it to mangle top-level identifiers.

[tivac]

There's currently no way to know which file caused in invalidation, as far as I can see — again, a nice-to-have

Does rollup/rollup#2405 solve that? You could write a tiny custom plugin that adds a function for the watchChange hook and reports it back up where it needs to go somehow.

[tivac]

Oh, and another problem/TODO — output filenames aren't hashed, which causes the usual caching nonsense with service workers. We could use rollup-plugin-hash but then we wouldn't be able to reliably determine where the entry point was in the output client directory.

Doesn't the bundle object returned by rollup.rollup() have that information?

[maxmilton]

Very exciting to see rollup support underway! I've been playing a lot with Closure Compiler + rollup + Svelte recently so maybe there's something I can help with there. I've been able to get reasonably simple Svelte apps to compile (e.g. this project) but it would be interesting trying to get Sapper bundles compiling.

[Rich-Harris]

I don't know whether this will help, but Terser does have a module: true option that will (among other things) cause it to mangle top-level identifiers.

Oh, fantastic. That's definitely going to help if we end up using native modules (currently trying to figure out if we're better off with AMD/loadz0r or ESM/Shimport — currently leaning towards Shimport).

Does rollup/rollup#2405 solve that?

Huh, you'd think I'd have known about that. Yes, probably. Not so sure about the bundle hashing stuff (in watch mode), will have to investigate further.

I've been playing a lot with Closure Compiler + rollup + Svelte recently

Ah, nice — I'm using Terser currently because of the bug I mentioned, but I'd like to use Closure if it turns out to have better compression

[tivac]

I usually use dir : "./dist" and it works fine in windows, if it helps at all.

[Rich-Harris]

huh. will try that next. thanks!

[Rich-Harris]

I don't get it. It's just not creating a dist folder on Windows. God I am so tired of wasting time to indecipherable Windows bullshit every time I try and make something

[tivac]

I'll try to pull this down and test locally to see if I can get you some more windows data points. Debugging via CI is the worst.

[Rich-Harris]

Thanks — I've just figured it out. On Windows, an npm task that calls rollup will try and execute a file called rollup.js (and not in Node, just as a regular executable) instead of $PATH/rollup. Why? Who the fuck knows

[tivac]

On Windows, an npm task that calls rollup will try and execute a file called rollup.js (and not in Node, just as a regular executable) instead of $PATH/rollup.

Interesting, I've never run into anything like that before!

[Rich-Harris]

Ok, we have a working Sapper app built with Rollup, using native JavaScript modules: https://sapper-template-rollup.now.sh/

If the tests pass (come on AppVeyor, don't let me down now) then I'll merge this in and release 0.18. Since Rollup doesn't support HMR, I'm going to add livereload functionality to the dev server in a follow-up release soon after. Will open a separate issue for that.

[elcobvg]

Great success! Seriously, this is cool. Will I be able to switch my current webpack project to Rollup?

[Rich-Harris]

@elcobvg yes! As long as your app is capable of being built by Rollup (a handful of modules, sadly, just can't be converted from CommonJS to ESM because they abuse inline require calls etc) then you should be able to convert it. It's exactly what I did at work this week, and it resulted in 25% less JavaScript.

This repo has a sample set of Rollup configs to crib from: https://github.com/Rich-Harris/sapper-template-rollup/tree/master/rollup (will be moving it into the sveltejs org soon).

Let me know if you run into any problems!

[elcobvg]

Thanks, I will try it out and see how it goes. If I learn anything that's worth reporting, I'll do so.

[kylecordes]

Further reducing the already small builds, it is so impressive. (Though perhaps a bit unsportsmanlike to "run up the score" :-) )

[elcobvg]

@Rich-Harris, I get these errors when firing up:

✗ server
no parsers registered for: "].htm"
✗ client
no parsers registered for: "].htm"

Which very likely has to do with the fact that I'm using regexp patterns in my routes (see: #283 )
Report this as a separate issue?

(FWIW, the errors come from snapdragon:parser)

[maxmilton]

Experimented with using Closure Compiler today but ran into some blockers due to upstream issues. Opened an issue in the template to track this: https://github.com/sveltejs/sapper-template-rollup/issues/5.

The upstream issues are:

• Not able to parse dynamic import ampproject/rollup-plugin-closure-compiler#48
• [FEATURE] Support dynamic import google/closure-compiler#2770

[Rich-Harris]

@elcobvg this is an issue in Rollup itself: rollup/rollup#2432. It can be worked around in the meantime by explicitly disabling globbing in your Rollup configs — add the following to client.config.js and server.config.js:

watch: {
  chokidar: {
    disableGlobbing: true
  }
}

@maxmilton nice, thanks for raising that. In Sapper's case Closure does need to be able to parse dynamic import(), since Rollup emits native ESM. So that might be a blocker...

[elcobvg]

@Rich-Harris that does indeed solve the problem. Thanks a lot!