Is hot-loading and code motion in the roadmap? about rollup HOT 36 CLOSED

Could someone please update us on the state of Hot Module Replacement in Rollup?

Good job on Rollup, I love it, thanks!

from rollup.

Hi @Rich-Harris !

Any news about Hot Module Replacement in Rollup? I'm using rollup with vuejs to build my apps for its simplicity but I really miss the HMR functionality.

Thanks for Rollup man!

from rollup.

This may be of interest to people in this thread.

Like many others here, I've been looking for a way to use Rollup for app development. I really love how simple Rollup configuration is, and that it doesn't try to do too many things. Webpack I've always felt has too many weird behaviours that are difficult to control. With Rollup though it's trivial to write a plugin to do exactly what you want. Unfortunately rebuild times with Rollup can be slow, and it was missing Hot Module Replacement.

I took the initiative to build an API-compatible bundler that mimics what Webpack does in development, but using the Rollup API and plugin eco-system, along with a dev-server. It's very much an alpha library, and missing lots of features still, but the dev-server does support HMR.

https://github.com/PepsRyuu/nollup

I would love to get feedback from people here, any thoughts you have would be great. :)

from rollup.

Any update on this? Thanks

from rollup.

Sorry for bugging. But shouldn't this be an open issue?

from rollup.

This should be in the FAQ.

from rollup.

Is there meanwhile Hot Module Replacement ?

from rollup.

I think a three month delay is sufficiently long to give this a good ol...

...bump! ;)

from rollup.

• Rollup is no server, so any browser-related things would need to be handled in plugin or tool country (e.g. rollup-plugin-serve). Please feel free to contribute there.
• Per-module HMR would not be easily possible with rollup due to scope hoisting
• With code-splitting, per-chunk HMR could theoretically be possible. However since ES modules are based on variable identity (i.e. in all modules you import {x} from 'y', x is the very same variable. In the same rollup bundle, is actually IS the same variable), there are many unsolved problems as to how a chunk could be switched while maintaining that identity.
• There is no work currently undertaken in this direction due to our limited resources

from rollup.

You would still need to get rid of scope-hoisting completely and instead add a runtime environment to keep the state of the non-switched modules. I personally do not really see the value yet, especially considering that such a setup would be very different from your actual rollup production bundle.

If you really want this, you could write a plugin that basically wraps each module into a loader function and adds a runtime environment that is loaded first and that each module registers with. But as I said, this would be very different from how Rollup works.

from rollup.

Note that if you use the SystemJS module format, hot reloading support can be provided through the SystemJS hot reloader project - https://github.com/alexisvincent/systemjs-hot-reloader. This project is a little old and hasn't been updated to SystemJS 2.0 but it does provide one path here.

from rollup.

In my opinion, Rollup aims to solve exactly one problem: Bundling ES modules together into a single module. It delegates other problems to third parties, such as parsing CJS, resolving node modules, and many other things that alternative bundlers like Webpack and Parcel delivers out of the box. This to me is a good thing, because it actually gives more control to the developer to achieve their goals, and helps to future-proof the project and keep it fast and lightweight.

Nollup is designed specifically for app development in the browser. What if someone wanted to target a different platform like a native app? What if someone wanted to use a different implementation of HMR that better suits their needs? There's a lot of open questions there that would have to be considered.

What would be handy actually, and not entirely sure how feasible it is, but if there was some sort of utility library that handles the plugin methods. My biggest concern right now with Nollup is maintaining consistency with the Rollup API. I'm just following what the Rollup API documentation says and haven't looked at the Rollup source code at all. At the moment there's great compatibility with common plugins, but there can easily be stuff I'm missing, and if Rollup changes the API, I'll need to mirror those changes.

That's just some food for thought! :)

from rollup.

Yep, that's my understanding and reasoning. I believe (though to be honest I'm figuring this stuff out as I go!) that what I termed LCI (in opposition to DCE) is more often called tree-shaking, though it seems that tree-shaking and DCE are sometimes used interchangeably since in a perfect world the end result would be the same.

The advantages of tree-shaking, as I see it:

• quicker, because unused modules don't even need to be fetched/parsed
• smaller, because there are limits to what DCE can achieve in JavaScript

The disadvantage is that you need to have an entry point. In some other languages that's easy, just include anything transitively referenced by the Main method. JavaScript doesn't have that, so a minifier doesn't have any way of determining where to start from and must instead work backwards, repeatedly eliminating any unreachable code until it can't find any. With Rollup, you can (and must) specify an entry point (which also determines what gets exported from the bundle).

In theory, code motion/splitting of the kind described in that blog post should absolutely be possible. One of the defining features of ES6 modules is that the boundaries between them are much more porous. The tricky part, once you've split src/foo.js and src/bar.js into bundle/foo.js, bundle/bar.js and bundle/common.js, is importing code from common into foo and bar, since at that point you need an asynchronous module loader; no self-executing bundles. But if you can assume something akin to Require.js or System.js is on the page, that's not a problem.

Of course, theory is one thing, implementation is another...

from rollup.

Interesting point! I assume the SystemJS reloader project could easily act on chunk level for us. I.e. if you use code-splitting, you could replace entire chunks.

Implementing code-splitting chunk based HMR would be much easier to implement for us than module based HMR as it could basically be an elaborate chunk finalizer. This would make it a little more difficult to set up useful HMR but it can be done. Imagine an application uses a central flux-like (redux etc.) store for its state. Then if this is put in its own chunk and making sure it does not depend on other chunks (which is usually the case for a store), changes to any secondary code could be hot reloaded without losing state.

Would require some nice tutorials for people to get the hang of this AND a good rollup dev server with a socket connection to orchestrate this. Would also put some steam behind enabling custom finalizers.

I would focus on the dev server first as this has a lot of value beyond this.

from rollup.

@lukastaegert we've already got a really good base web serve in rollup-plugin-serve and there are a few others out there under the radar which nicely leverage sockets (better than I had done in webpack-serve) for handling live reload. The foundation for the dev server is there. (and refining those into a dev server is something I've had on my list for some time).

If you can handle the HMR setup and get a sample project going, I can handle the dev server.

from rollup.

@PepsRyuu this sounds awesome!

Update: Is Nollup different enough that some of the basic ideas wouldn't make sense to include in Rollup?

In other words, flipping that question around, what if Rollup had some dev-only features that did a lot of what Nollup is doing? Is this worth exploring more in a different ticket?

from rollup.

It's definitely something I've been thinking about, though 'roadmap' is probably putting it a little strongly 😄 For now the priority is to figure out all the steps necessary to produce the smallest bundle possible while ensuring nothing gets excluded incorrectly – I think we're most of the way there, though there's still the odd false positive (and possibly false negative, which is worse).

HMR is definitely the future. It complicates things significantly, because obviously you need a server and a client, and that's all well and good if you're doing a simple static project but gets significantly more complicated beyond that, because suddenly you have to juggle a bunch of moving parts. And ideally there'd be as little tool-specific stuff (i.e. module.hot.accept) as possible. (StealJS does a better job of this part IMHO – you explicitly import a live-reload module and pass it a callback if your module needs to do anything on update. Though I haven't spent any time with Steal or dug into its code yet.)

The other consideration is that a lot of Rollup's logic is devoted to bundling, but for a dev workflow that includes HMR you want to serve modules individually (maybe not as individual files, per se, but the module loader needs to be able to think of them as separate things). So is it something that Rollup should be concerned with, or should a different tool handle the development workflow then hand off to Rollup at deployment time? I don't know, these are questions that require exploration.

I'm actually surprised other bundlers like Webpack hasn't yet figured out the "let's exclude stuff we don't need" idea

I think it's more that it's just not possible to do effectively with CommonJS modules (and Webpack deals with CommonJS-ish modules, even when you're authoring ES6), because the syntax doesn't allow it – CommonJS is woeful for static analysis compared to ES6 (not a criticism, CommonJS didn't have the luxury of adding new JavaScript keywords). My hope is that as people become aware of the benefits of ES6 modules, they'll shift towards ES6-native tooling. Or maybe browser vendors will hurry up and implement module support...

from rollup.

Thanks for the thoughts - I'm definitely looking forward to HMR being added in the future. If Rollup excels at creating the smallest bundle possible, I'm sure it will win many a person's heart.

According to @swannodette, another feature Webpack lacks is code motion across modules.
http://swannodette.github.io/2015/02/23/hello-google-closure-modules/
It'd be cool to see adventurous features like that and HMR get added to Rollup. Hope I'm not sounding demanding - just expressing my excitement :)

from rollup.

Heh - Rollup was partly inspired by a different @swannodette blog post (http://swannodette.github.io/2015/01/06/the-false-promise-of-javascript-microlibs/), the main point of difference being that Dead Code Elimination doesn't work particularly well in JavaScript (outside Google Closure Compiler), so we need to practice Live Code Inclusion instead.

from rollup.

Hmm, trying to organize what I'm learning from ya. Please check my understanding for me:

• DCE works well in Closure thanks to Closure-specific comments and code
• But it doesn't work well outside Closure-specific code
• So we need to think in a fundamentally different way. Instead of getting rid of unused code, do the opposite thing: include code that does get used.

Is that correct? If so, I wonder why Closure didn't choose LCI over DCE. What are the competitive pros of each approach?

Also at this point it sounds like HMR and code motion are both indeed possible in Rollup, right? Someone just has to do the work :)

from rollup.

Ah, tree-shaking, got it. Having an entry point is definitely something people can get used to (people happily do it over in the Webpack world!).

I'm happy to hear that advanced features like DCE and code motion are in the plans. Perhaps I should dive into the codebase soon so I can help implement those features in the future. Thanks for all your comments.

from rollup.

+1 that would be super awesome

from rollup.

@Rich-Harris am looking at Rollup as webpack replacement for Vue development.
But, not seeing a clear answer to the question of whether Rollup has hot-reloading (i.e: maintaining state of components in browser)?

Thanks
Dave

from rollup.

Could someone chime in with the general direction of how this should be implemented?

I would spend the time doing it.

from rollup.

Just like jspm let the tree shaking part be handled by rollup, you could let jspm handle hot-reloading using the -wid flag

from rollup.

Sorry for the revive, but is there any news here? A dev-branch we can look at maybe?

from rollup.

@thomasdavis We may do some thing like this.

// client side(browser)
import {x} from './mod.js'
ObserveModule('./mod.js').then(new_module=>{
    reload(new_module).then((module)=>{
        x = module.x
    }); 
}

// server side (e.g. rollup-plugin-serve)
server.listenModule = mod =>{
    OnFileChanged(mod).then(new_module=>{
        server.broadcoast_to_client(new_module); // e.g. 'mod.js?version=2'
    })
}

Maybe we should extend the livereload and rollup-plugin-serve to support HMR.

from rollup.

I personally do not really see the value yet

Sally sad face. There's tremendous development value in not having the whole application refresh (losing state!!!) and just echoing the portion of that thing being worked on.

I'll be seriously disappointed if this loses steam.

from rollup.

If you really want this, you could write a plugin that basically wraps each module into a loader function and adds a runtime environment that is loaded first and that each module registers with.

@arxpoetica that right there ^ sounds like an excellent way to contribute and pump some steam into this. lukas makes a really excellent point that I think gets overlooked too often, in the name of ooo-shiny. there is high value in consistency, especially for testing.

On a related tangent: there has to be a way for your preferred state management component for your preferred framework to pre-load a state for testing. (And if there isn't, that's another good opportunity for contribution) And if there is, a plugin like rollup-plugin-livereload would come in handy.

from rollup.

@shellscape I don't disagree; unfortunately, I don't have the time to contribute. shrug

My hope is just that this doesn't fall to the wayside based on perceived value. I've watched Rollup almost from the beginning, and it's one of the top items I've hoped would land. But you're right, that would be solved much more easily by putting my money where my mouth is. I wish I had time to commit to it.

from rollup.

Great work @PepsRyuu! Can we add this to https://github.com/rollup/awesome?

from rollup.

Thanks for the feedback @guybedford! I don't mind at all, feel free to share the link. :)

from rollup.

My biggest concern right now with Nollup is maintaining consistency with the Rollup API.

This exact thought was driving my question ^^

Awesome plugin though. Can't wait to try it out.

from rollup.

My question would expand on that by @arxpoetica: are there parts of Nollup that can be used on/with Rollup via a plugin or directly via PR to core?

from rollup.

Just curious, what is "code motion"?

from rollup.

Some time ago, I wrote a hot-reload module called ReloadSite. It wasn't perfect then but served me well. Lately I have been writing a lot of Svelte code thus started using Rollup a lot. I fount a way to hack ReloadSite into the process but it was ugly and slow.

Today I rewrote parts of ReloadSite to make it a superb 100% HMR module then made the simplest HMR Rollup plugin. Really happy with the outcome and I would love to share rollup-plugin-reloadsite with all of you.

I still have to finish the tests but it works like a charm so far. Try it and give me your feedback.

from rollup.