systemjs-hot-reloader is searching for Maintainers!

[alexisvincent]

This issue was created by Maintainers Wanted 🤓

Support us by leaving a star on Github! 🌟

systemjs-hot-reloader is searching for new Maintainers! 👨‍💻 📬

Do you use systemjs-hot-reloader personally or at work and would like this project to be further developed and improved?

Or are you already a contributor and ready to take the next step to becoming a maintainer?

If you are interested, comment here below on this issue 👇 or drop me a message on Twitter! 🙌

[guybedford]

@alexisvincent this is a critical project for SystemJS going forward, especially since it allows hot reloading workflows for Rollup build workflows (rollup/rollup#50 (comment)).

Ideally such workflows can be refined to work with SystemJS 2.0.

Please let me know if get any response here.

[alexisvincent]

@guybedford It's cool to see the direction SystemJS is heading. As I mentioned, I really don't have time to work on this project in the manner that it needs. Happy to discuss the best way to construct a healthy future for the project.

Ultimately the systemjs-hmr project was designed as an extension to SystemJS, adding the System.reload function. The logic is thin and perhaps this could be a time to talk about integrating with SystemJS 2.0 as an officially supported function. This would seem to fall inline with where you might want to take SystemJS. This project could remain a thin wrapper on top adding the socket connection logic.

Who is your target audience for the SystemJS project going forwards?

[alexisvincent]

Looking over some of the new features with SystemJS 2.0, I'm pleasantly surprised by some of the new features. Package name maps for instance would make a better build target for systemjs-config-builder. Having a JSPM CDN is awesome and realises the goal of this discussion which never went anywhere. And loader seems like something that might be easier to build HMR against.

[ArmorDarks]

Are there any hopes for an update for JSPM 2? I do not imagine how development even possible with JSPM 2 and without HRM, since it doesn't even have a builder with a watcher, on contrary to the JSPM 0.17. And loading large project "as it is" is a nightmare, like in good old times of the JSPM 0.16...

[alexisvincent]

@ArmorDarks Assuming the hot loader is updated to support SystemJS 2.0, working with JSPM 2 should be seamless, since this is supported at the package mapping level. systemjs-hot-reloader only reloads files that have transitively changed and since packages on jspm fixed to some version are immutable, they won't need to be changed once loaded into the module loader.

[ArmorDarks]

Right. Then can we hope for SystemJS 2.0 support update? :D

[alexisvincent]

Not from me :) But I think @dazinator might have something in mind?

[dazinator]

To support systemjs >= 2.0 there is an issue here: alexisvincent/systemjs-hmr#34

To date, I have only fixed a few minor things to support 0.20 and 0.21.X which @alexisvincent kindly merged.

I'd like to take a look at supporting system 2.0 but I am perhaps not best placed at the moment. It would be helpful though if someone who is familiar with 2.0 could offer some guidance on how we can support it with minimal changes. Ideally i think we would love to keep a single hmr library supporting all systemjs versions from 0.19 to 2.x but if the changes are so significant perhaps its best we drop support for < 2.0 and re-write the hmr experience based on 2.0 apis (I dont know this but thos is the kind of thing that would be useful to know to gauge effort). If anyone can help please comment on that issue!

[guybedford]

SystemJS 2.0 was designed with hotreloading in mind with a couple of features:

1. Registry API with delete and get only https://github.com/systemjs/systemjs/blob/master/docs/api.md#registry-api-systemjs-only
2. onload hook for tracing - https://github.com/systemjs/systemjs/blob/master/docs/hooks.md#onloadurl-error-sync

The above are exactly the minimal features for hot reloading and are there waiting for someone to pick up this baton!

Happy to discuss further.

[alexisvincent]

Thanks @guybedford, API definitely looks good from an hmr perspective. I haven't taken time to look into this, but there are some additional things I remember wanting, especially around allowing modules to unload themselves before deleting from the registry. Was important for js, css, etc. which all interact with global scope or DOM. I think I might have built this into systemjs-hmr already.

Happy to provide support to anyone willing to give this some time. I expect it to be relatively straightforward.

@guybedford to what degree is SystemJS 2.0 backward compatible from an application perspective.

[guybedford]

Yes, exactly some kind of convention / pattern for that on top like you had works great. Building it into core still seems unnecessary though, I still like the two layer approach.

SystemJS 2.0 is not backwards compatible from an application perspective.