add autoreload to trunk serve

[kcking]

Thanks for building trunk! It's such an awesome tool.

I took a pass at implementing a simple autoreload that is triggered by an injected websocket script. It is exposed by a --autoreload flag that defaults to false. It looks like my rustfmt did some collateral formatting in a couple of files, I can manually revert it if need be.

Let me know what you think!

Checklist

• Updated CHANGELOG.md describing pertinent changes.
• Updated README.md with pertinent info (may not always apply).
• Squash down commits to one or two logical commits which clearly describe the work you've done. If you don't, then Dodd will :).

[thedodd]

@kcking thanks for the PR! Stoked to see this feature being implemented. A few initial comments, let me know what you think.

[kcking]

Thanks for the review @thedodd! All your comments sgtm, I'll address them shortly.

[kcking]

Ok just addressed those comments, let me know if there is anything else!

I changed the flag name from autoreload to no-autoreload since it is now enabled by default. This seemed simpler than using --autoreload=false to disable it, but let me know if you think there's a better way.

[thedodd]

@kcking sorry to make your PR more difficult! The Tokio cut over is complete, so there are a few conflicts and such. I do think the code will be a bit more simple now though.

On a high level, given Tokio's significantly better messaging support, we should probably use a tokio::sync::watch channel, which new WebSocket connections will simply subscribe to and then listen for changes on the channel. For this initial autoreload support, I don't think we need to propagate compiler error messages or anything like that. We can just emit a new value over the channel upon a successful build.

In the future, we can actually propagate a structure message over the websockets so that we can create a diagnostics overlay or drop the info in the console and such.

[kcking]

Sounds good! I should have time tonight to fix this pr up Sent via Superhuman iOS ***@***.***>

…

On Fri, Aug 6 2021 at 8:07 AM, Anthony Dodd ***@***.***> wrote: @kcking <https://github.com/kcking> sorry to make your PR more difficult! The Tokio cut over is complete, so there are a few conflicts and such. I do think the code will be a bit more simple now though. On a high level, given Tokio's significantly better messaging support, we should probably use a tokio::sync::watch channel, which new WebSocket connections will simply subscribe to and then listen for changes on the channel. For this initial autoreload support, I don't think we need to propagate compiler error messages or anything like that. We can just emit a new value over the channel upon a successful build. In the future, we can actually propagate a structure message over the websockets so that we can create a diagnostics overlay or drop the info in the console and such. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#191 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKJIU7KMK57CPBDHNZKVT3T3P3CRANCNFSM47V3B5HQ> .

[kcking]

@thedodd alrighty just updated this PR to support axum/tokio. Let me know if there's any other changes on your mind :)

[thedodd]

Awesome! I'm going to merge this in a few hours, I need to go AFK for a bit though. Really excellent work @kcking! Thanks!

Notes for myself for after I merge this:

• Add docs about this feature to the site.
• Add docs for this config var to the default Trunk.toml.
• Add to config cascade.
• Add a todo/note in the code about future emission of error info over the socket.
• Probably move code injector the HTML pipeline.

[kcking]

Awesome! I'm going to merge this in a few hours, I need to go AFK for a bit though. Really excellent work @kcking! Thanks!

Woo! Thank you for the review and for the awesome tool :)

[thedodd]

🎉

[thedodd]

BTW, @kcking you should totally join our discord server so that I can give you a shoutout for this work :)!

[chetankhilosiya]

Great work. I am eagerly waiting for this feature to become available as release.