Framework: [Feature Request] Bundling with Rollup

[bigopon]

I'm submitting a feature request

• Library Version:
  1.0.*

Please tell us about your environment:

• Operating System:
  all
• Node Version:
  6.8.0
• NPM Version:
  3.8.9
• Browser:
  all
• Language:
  all
• Current behavior:
  No Rollup support
• What is the expected behavior?
  Support to build Aureliaapplication with Rollup, besiderequirejs,webpack&jspm`
• What is the motivation / use case for changing the behavior?
  Rollup helps deliver smaller bundle as faster initial loading time.

[EisenbergEffect]

We are researching this for the CLI

[EisenbergEffect]

@bigopon Any interest to do some research on this. I've done a bit myself. There was another community member looking into it but they haven't done much. It would be a nice contribution if we could somehow switch amodro trace over to rollup.

[bigopon]

I was researching a bit before. But I'm neither Rollup nor Aurelia expert so I cannot really guarantee anything.

[stephenlautier]

@EisenbergEffect if i use rollup without aurelia-cli, would it be possible to get it working? or it needs some new bootstrapper/loader?

[EisenbergEffect]

It should work, but rollup may not be able to find all the dependencies. I'm not sure if you can pass dependencies along to rollup manually. That's one of the questions we have.

[bigopon]

cc @niieani @EisenbergEffect
From the look of the votes here Webpack votes - https://webpack.js.org/vote/

I think we will see scope hoisting in webpack soon, thus remove the need for rollup. If you agree maybe this issue can be closed.

[jods4]

Chiming in because I have this in mind while working on webpack integration.

The secret sauce in rollup is (a) tree shaking and (b) scope hoisting.

The latter is currently worked on by webpack team. Some discussions happened in webpack/webpack#2873.

The former works in webpack 2 -- but only with ES6 import.
That said, Aurelia is _fundamentally not tree-shaking friendly_. And for pretty much the same reasons it's not very lazy/async/deferred loading friendly either.
This is something that probably needs improving but it also needs some re-thinking of a few fundamentals.

One last consideration that makes both points harder is that Aurelia is doing a significant amount of dynamic loading through aurelia-loader. Whatever build/runtime is used, care is required so that those modules are still loadable at runtime, with appropriate name (or mapping) preserved.

[atsu85]

@jods4
what do You mean by

Aurelia is fundamentally not tree-shaking friendly. And for pretty much the same reasons it's not very lazy/async/deferred loading friendly either.

?

[bigopon]

@atsu85 you will find your answer here rollup github homepage. Basically it can't be shaked if you use commonjs. Only ES6 import / export statement can be analysed.

[jods4]

@bigopon
That's not what I meant. Aurelia has es2015 and native-modules in its dist and that could be tree-shaken. (Assuming your code also uses ES imports)

@atsu85
Let's say you want to use an aurelia charting lib. Maybe it's big.
What you are likely to do is .plugin('charting-lib') in your config.
And at this point (startup), it will load and execute the lib and probably register all its resources with (.globalResources('./pie-chart', './bar-chart', ...)), which will execute each of those modules.

Consequences:

• you can't lazily put the charting lib code in the bundles that actually use them.
• you can't tree-shake any control because they are all executed, whether or not you actually use them.

Even aurelia itself does that. For example when you call .standardConfiguration(), it will .plugin('aurelia-templating-resources'), which will .globalResources() all of if, compose, repeat, etc.
And so you can't treeshake any of the built-in components, even if you don't use them.

To be fair, there is one solution that works today: use local resources with <require> only.
But global resources are much easier to use, that's why all libs use the global pattern.

I have not thought this through, but what could be nice is give plugins a lightweight way to declare their global resources _without_ actually fetching and executing them. The execution would then only occur the first time a view requires the resource.

For instance, at startup .plugin('charting-lib') would only fetch a manifest that says: "I expose a pie-chart custom element here ./pie-chart, and a bar-chart custom element there: ./bar-chart". Then aurelia would load and execute those modules _lazily_ when such an element is encountered.

If the build process is also aware of that, it can trace dependencies from the views to the modules they actually use and that could lead to tree shaking and properly splitting code in separate bundles. And it would make startup faster.

Another aspect is that Aurelia uses a lot of barrels files. By that I mean: re-export everything in a single file for convenience. For example, aurelia-framework exports tons of stuff from aurelia-binding and co.
Even if you don't use those exports, it makes it slightly harder to split all dependencies and completely tree-shake everything. Your build tool _will_ cut exports and remove dead code but it will have a hard time completely removing the import "aurelia-binding"; from aurelia-framework. The reason is that in order to do that it must be able to prove that the import has no side-effect, even if you don't use any of its exports.

[jack4it]

@jods4 Impressive explanation, thanks! @EisenbergEffect Would really love to see some overall plan of making this work. Not just the framework itself will be shakable, but also the entire ecosystem would be.

[EisenbergEffect]

I think the first step is getting a solid webpack build with HMR, server-render and basic tree shaking in place. Once we have that, we can look at how we might be able to re-organize things in such a way to improve tree shaking. In a separate issue I've outlined a few ideas on how we can do some refactoring to reduce size of a few pieces. We have to be careful about the timing of this, because to do what @jods4 is suggesting would be a major breaking change to almost every Aurelia library. If we're going to go and do that scale of a change, we want to be strategic about that and probably use it as an opportunity to address a few other items as well. I think it's too soon to do all of that just yet. I also think we're likely to mess it up if we are pre-mature about it, in which case we drive the entire community into a period of instability. So far, we have a great track record as a framework of not breaking our community. So, when we do that, I want it to be very carefully planned and with minimal pain for our community, with lots of explanation, advance warning and as simple as possible a migration plan.

[deleonio]

Hello.

In the last weeks I compare some spa frameworks and there build processes. Without CLI's. The reason is, that in commercial projects we have different requirements.

So I am realy interessted to use Aurelia. I like ES6 code style.

Maybe I can help. But where I can read the aurelia magic in build.

[jdanyow]

@martinoppitz this repo contains several sample projects that do not use the Aurelia CLI:
https://github.com/aurelia/skeleton-navigation

This repo contains examples that use no CLI:
https://github.com/aurelia/aurelia

Here you can read about setting up a minimal aurelia project from scratch:
http://stackoverflow.com/questions/32080221/how-to-set-up-minimal-aurelia-project-from-scratch

[deleonio]

thanks @jdanyow

[bigopon]

Closing since we have better application for Rollup now: prebundled Aurelia in esm / umd format.

[lemoustachiste]

Hello,

I might be missing something silly (a flag to npm or something), but I can't figure out how to load the es2015 for all the aurelia packages.

Rollup is failing on:

Error: 'initialize' is not exported by node_modules/aurelia-pal-browser/dist/commonjs/aurelia-pal-browser.js
node_modules/aurelia-bootstrapper-webpack/dist/es2015/aurelia-bootstrapper-webpack.js (2:9)
1: import 'aurelia-polyfills';
2: import { initialize } from 'aurelia-pal-browser';

I am currently doing manual imports such as

import { Aurelia, LogManager } from 'aurelia-framework/dist/es2015/aurelia-framework.js';

And that works, until I hit internal files imports.

I guess I could work around that:

• using replace in rollup, but that's going to be tedious
• using commonjs plugin to define the exports, but I feel that's even more tedious.

Is there an easy to tell aurelia to look for the es2015 folder rather than the dist?

Thanks

[bigopon]

@lemoustachiste Can you check your version of aurelia-pal-browser? it has field "module" in its package.json pointing to es2015. In theory Rollup should have automatically picked that up

[lemoustachiste]

Thanks, I'll look into it. I am working with a somewhat legacy project so
indeed, I didn't look at updating dependencies first.

On Mon, Dec 17, 2018 at 10:09 PM bigopon [e-mail] wrote:

@lemoustachiste https://github.com/lemoustachiste Can you check your
version of aurelia-pal-browser? it has field "module" in its package.json
pointing to es2015. In theory Rollup should have automatically picked that
up

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/framework/issues/642#issuecomment-447999634,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMNICj7Yo7qn1tY-l6BCJm3CLC_ZB3gtks5u6AgSgaJpZM4Kguvy
.