#The Future of Hot Reload

1 messages · Page 1 of 1 (latest)

final crystal
#

Hello developer friends! We want to collect some important feedback from you that will help inform our prioritization of V14 features.

As some of you may (or may not) know, Foundry VTT has a dev tool feature called "hot reload" which allows you to configure that Foundry VTT should automatically update in certain ways when CSS, HTML, JS, or localization JSON changes.

Problem Statement

This feature was added as a passion project (Free Project Friday sort of thing) but is not something that our team internally uses and it creates some considerable maintenance burden for us in order to keep this feature working with other new innovations we are making in Foundry VTT. A brief summary of issues includes:

  1. Changes to ApplicationV2 and support for partial template rendering are not yet supported with hot reload without additional investment.
  2. The upcoming Application pop-out feature in V14 will not support hot reload without additional investment.
  3. Changes we want to make to improve the localization framework will not work with hot reload without additional investment.
  4. As we move more heavily towards ESModules there are some aspects of ESM loading that create edge cases issues with hot reload.
  5. When we moved to CSS layers, we had to implement a patch for hot reload that is imperfect and likely requires revisitation.

Additionally, there are several known bugs listed here: https://github.com/foundryvtt/foundryvtt/issues?q=is%3Aissue state%3Aopen hot reload

In addition to these current issues hot reload imposes a continual maintenance burden on our team which - every generation - will likely require some further changes.

Proposal

Our team would (unanimously) like to entirely remove the hot reload feature from Foundry Virtual Tabletop and no longer support it starting in V14 onwards.

In exchange for abandoning this feature, we would be able to invest a significant amount of developer time (probably about 2 dev weeks) into other value-adding features that would make Foundry Virtual Tabletop better or easier to use. We could specifically target that time towards addressing a range of API bugs or pain points which are impactful for the developer community specifically.

Collecting Feedback

We realize that removing a feature is hard to stomach because it feels like moving backwards, and for some of you who actively use hot reload this may be an unacceptable proposal. We don't know how many people fall into that category though, so we are conducting a poll to assess how broad and severe the impact would be of us removing this feature.

Please vote in the poll below and let us know how (if) you use hot reload and whether you are comfortable with the proposition that it be removed in exchange for other value adding changes.

#

Poll Definitions

Please choose the option in the poll which most closely aligns with the following definitions:

Aware + Essential

I actively rely upon hot reload and would be significantly worse off if it were removed.

Aware + Not Essential

I use hot reload, but I am comfortable shifting to other tools or workflows.

Aware + Not Used

I know about the existence of hot reload, but I do not use it.

Unaware + Essential

I did not know about hot reload, but now that I do I think it is essential to exist.

Unaware + Not Essential

I did not know about hot reload, but now that I do I think it could be removed.

viral sphinx
#

I never got it to work

spare briar
#

i beg for at least the CSS hot reload to stay...though i use HBS as well.

CSS hot reload has saved me so much time 🙏

mortal bobcat
#

If we end up with "Let's remove it": Would it be possible to instead leave the basic infrastructure for hot reloading (i.e. the server watching for changes and calling a hook) in place, leaving the actual hot reload implementation to modules?

rose nimbus
#

A partial option would be interesting ... just CSS hot reload is pretty good already - all I've ever needed.

tacit pagoda
#

I'm quite interessted in what the time would be invested in exactly, if hot reload ends up removed

versed meadow
#

Good old F5 has always worked for me, I never cared enough to go through the effort of figuring out how to set up hot reload stuff.

spare briar
#

its a flag and thats it

last mirage
#

Specially if you start the development process it is super important imho

heavy estuary
#

I actively use hot reload a lot during system development, but I understand the development burden if it's unable to be maintained long-term. I wouldn't say it's essential but it'd slow down my development time a little, so as long as the effort that would've been spent maintaining it is put somewhere else, I'm okay.

rocky umbra
#

I just used Vite and it worked flawlessly 👍

spare briar
#

CSS reload is trivial, HBS is as well, but there are some issues with deeply embedded parts

frail bluff
#

When I've needed to test quick css changes I've simply done it in the dev tools

rocky umbra
#

So the Foundry one can be removed for all I care

gleaming forge
tacit pagoda
final crystal
#

I think the extent to which setting up Vite is easy is ... debatable.

placid pulsar
#

CSS reload is very useful, but I can live without it.

final crystal
#

but it certainly is a functional alternative.

rocky umbra
#

Also very easy to code in HMR in Vite, like Hook reloading and even Application reloading

forest aspen
mortal bobcat
queen grail
#

I use it, but I can figure out alternatives if needed. The HBS portion has never fully worked for me since half of my systems use Vue as an alternative renderer.

forest aspen
#

Vite isn't that hard to set up, but it's non trivial, so implementing a framework would remove some of that blockage

vast latch
granite token
rocky umbra
jade loom
#

please dont remove hot reloading (of css) ❤️

spare briar
vast latch
#

I spent literal weeks writing a webpack plugin and learning the codebase and I just switched to Vite and it was soooo much easier

queen grail
#

Keeping CSS reloads would be nice for new devs IMO if that’s possible.

eager quarry
#

CSS reload is very useful for quick tuning, but wouldn't kill me if it's removed

keen bolt
#

Personally, I never have gotten CSS hot reload to work, for me only JSON & HBS reload works.

I have voted 'Not Essential', but will express that the one I am gonna miss most is the JSON one, I feel like this will likely result in localization becoming more of a pain in the ass.

Ultimately, since JS Hot Reload doesn't work(/exist), when I'm building an App V2 app, to get any interactivity done, I require to refresh anyways. So if I'm being realistic, this will probably increase the amount of refreshing I need to do by like 15-25%, which I can live with 😛

cunning flare
#

I find the CSS hot-reload the most useful and would like to see an alternate if possible. F5 works fine for code changes.

rocky umbra
jade loom
#

I mean you can theoretically develop something in a local html file that loads all the css rules from base foundry + your custom stuff but uh... its a kinda annoying work around...
And obviously application specific stuff (like resize, drag) wont work there...

spare briar
#

oof, the poll isn't looking good 😩 I'll have to rebuild hot reload into my rollup plugin (badger den)

desert rune
#

What does the removal of hot reload implies ? Do we will need to restart the server and redo all the login process to launch and join the game every time we do a change in our systems/modules ?

frail bluff
forest aspen
#

F5

jade loom
rocky umbra
#

Just like before hot reloading

#

Or if you hadn't implemented hot reloading

spare briar
desert rune
#

Wait, what ? We didn't needed to do that ? Since when ?

rocky umbra
#

Only for CSS

spare briar
#

and HBS

rocky umbra
#

Everything else pretty much required coding out your own solutions

#

-# And by that point you might as well just go for something more standard

lunar moth
#

CSS reloading is what I care about, there are other things I like but CSS being used the most.

mortal bobcat
final crystal
rocky umbra
supple raven
#

Hot Reload is an enormous QOL feature for any development I do in Foundry, both premium and free.
I suck too much at CSS to want to hit F5 after every change and there's no way I'm going back to copy/pasting dozens of lines from the browser to my css files. Same goes for HTML but to a lesser extent. 'Essential' doesn't do it justice for my purposes.

If hotreload won't work on popped out applications in v14, then whatever, so be it. That seems minor.

cunning belfry
#

Is it nicer with it than without? - yes.
Is it essential? - I don't think it is.

torn lava
#

If Hot Reload is taken out, maybe a well written, up-to-date, and maintained tutorial on how to get a development environment set up with Vite and its hot reload

jade loom
#

can someone tell the firefox devs that I want to edit my CSS file inside the browser please? thx

torn lava
#

I’ve tried getting vite set up before and ran into serious friction

spare briar
#

i looked into it briefly before using rollup and having a much easier time

rocky umbra
versed meadow
steep cargo
#

HMR is like way down at my list of things I'd like to have

#

it starts with basic stuff like documentation and types

jade loom
keen bolt
steep cargo
#

developer migration guides when you break APIs (see how popular frameworks like angular or react do it)

frail bluff
spare briar
#

(lets stay on topic plz)

royal fox
#

I fully agree with Zhell above. This is an essential feature for me, and for people are not professional or experienced developers (which are a few, and which is one of the great things about Foundry). If I'm only doing css/localization, and I'd had to press F5 every single change (not an expert, a lot of trial and error), I'd get frustrated at some point.
And I also can't just use Vite or any other setup, I have no clue about that and we won't change our entire code base for that.
I can see the difficulties, but this is one of the biggest QoLs I see in Foundry...

spare briar
#

omg, i forgot localization files

#

that is like magic

#

dropping in the i18n keys while coding then filling them in after the app renders is so nice

steep cargo
rocky umbra
#

localization HMR doesn't seem to be an issue so it would be nice if it were to be kept

keen bolt
spare briar
shadow snow
#

For CSS and Localization, I'd miss it.

supple raven
#

In exchange for abandoning this feature, we would be able to invest a significant amount of developer time [...]

I struggle to comment on this and compare cus it's too vague.

spare briar
#

(hence my misfire, yea -- i dont want this to spin out into conjecture and wishlists)

forest aspen
steep cargo
#

free project friday: write docs /s

queen quartz
#

I'd miss it, but I wouldn't call it 'essential'.

supple raven
#

if the two are mutually exclusive (i dont see why they would be), i'd honestly rather have hotreload.
at least without docs, you can look at the source code and internalize it over time. Lack of hotreload would be a persistent pain point.

steep cargo
cunning belfry
#

better docs reduce the entry level for new developers so we shouldn't do that to keep modules high quality

supple raven
steep cargo
#

yeah, it's more along the lines of "this is not fun, do we need this"

rocky umbra
forest aspen
#

I was half joking, but my underlying point is yes, I'd like to hear what the dev team propose to do with the saved dev time

marsh oracle
forest aspen
#

Also true, the existing type improvements have been great

timid aurora
#

People are talking about hot reload, but they are forgetting people, like myself that have two monitors and don't even use go the browser to see the result of their changes. So, hot reload going away is a very bad thing, because it will mean slowing down the speed to refresh everytime I do a change.

wicked arch
#

Is this "Hot Reload" required for F5 to function to use the latest files?
Or does "hot reload" allow us to edit the CSS and we automatically see the change without pressing F5?

rocky umbra
steep cargo
#

still the current state of docs is so bad that I've gone over to read code exclusively

marsh oracle
steep cargo
#

100k lines

marsh oracle
steep cargo
#

yes

#

but it's quicker to scroll to the correct location in the big files (using grep/vi)

supple raven
tropic goblet
#

I make pretty extensive use of vite and so personally I don't use the CSS part, but I rely pretty heavily on localization and handlebars reload. Plus vite isn't really a silver bullet here since it's not easy to configure based on the number of projects I've seen that use it configured in such a way that it's essentially just rollup. It's nice once set up, but getting there requires non-trivial amounts of work.

cunning belfry
steep cargo
#

localization reload would require a page refresh anyways I suppose

rocky umbra
steep cargo
#

CSS might be feasible, everything else runs into the same issues

marsh oracle
errant storm
#

My take on Hot Realoading

It never worked for JS as far as I know, so there is a lot of refreshing in my workflow already.
With Handlebars it sometimes worked, sometimes not, never paid attention what caused it.
With localization, I often run localizations early, like in i18nInit, so it also wasnt always useful for me.

But hot realoading CSS does help me tremendously, because I can test multiple options and variants on exactly the same structure, without having to retrace steps to render an app.

If the last part could be achieved somehow else, I wouldn't mind not having hot reloading in general.

vast latch
marsh oracle
#

I use hot reload pretty heavily, but there are workarounds for most of my use cases

versed meadow
#

Pretty sure JS hot reload is fundamentally impossible, since it would require somehow being aware of what changes and mutations a line of code did and the prior state to undo them. That's fundamentally outside the scope of any discussion.

frail bluff
#

Easy, just when the js changes refresh the page /s

marsh oracle
frail bluff
#

Yeah I know, it's just not quite hot reloading

rocky umbra
#

That's why Vite is also a bundler and tree-shaker

vast latch
# versed meadow Pretty sure JS hot reload is fundamentally impossible, since it would require so...

Yeah so hot reload of JS is almost always regulated to frameworks with stronger assumptions for this reason.
For instance a lot of component oriented frameworks assume you can mount and unmount components without side effects and does that for hot reloading
See Svelte, Vue, React, etc.

conceptually similar to reloading a single Application at a time (except usually it's smaller pieces and there's tricks to avoid losing state)

rocky umbra
#

And also why it refreshes when it cannot faithfully execute such differential

rocky umbra
forest aspen
plush parrot
#

I really enjoy having Hot Reload in other JS/TS projects, but I wasn't even aware that it could work for Foundry -- I always relied on refreshing the page. I do think it would be a great QoL feature if supported, but only if it was also made to work automatically (or with very easy setup, ideally something that raises awareness too). otherwise, remove it and enjoy your extra dev time.

twilit zephyr
#

I just want to keep "I absolutely do not care if popped-out apps lack hotreload" in the discussion, I don't think that consideration should be given much if any weight.

carmine scaffold
#

I've been working on foundry mods since v7 and this is the first I've heard of it

marsh oracle
#

It only recently showed up in the docs

#

otherwise you had to know the specific gh issue that implemented it to know how it works

rocky umbra
#

its been since what, 12?

marsh oracle
#

no it got added like v10

rocky umbra
#

god, time flies then

#

I distinctly remember it being implemented and seeing the gh issues

marsh oracle
rocky umbra
#

but then again, all it amounted to in the end for me was i18n and CSS, basically packing that into every module.json template I did

#

now I look at it its funny it still worked for i18n jsons even if I didnt specify its path

spare briar
rocky umbra
#

ah, hello typhon

chrome_tNty9rp33k.png
#

Anyway if someone is interested in Vite setup I'd be happy to help or maybe write a guide sometime
I cast my vote, gotta get away from module cooking and back to cooking actual dinner 👨‍🍳

lapis spoke
#

If I was working only on one project, I could totally self-implement some hot reload mechanism and live without Foundry having one, but I work with nearly hundred tiny modules that don't use complicated setups with constant background building, that the Foundry provided hot reload has been a huge blessing.

vast latch
#

So you make edits to multiple modules at once? Genuinely curious.

#

like do you just have a world with all of your modules open and test them all at once?

lapis spoke
#

Not to multiple at once, they just don't have a build step.

final crystal
lapis spoke
vast latch
#

Well hot reload dev servers don't require you to have a build step

#

I've set it up before but admittedly it is more convenient if Vite is already building your code since it feels like it's already in arm's reach

lapis spoke
#

Setting up vite for hundreds of projects is a massive overhead.

#

Especially when that setup is larger than the project itself.

rocky umbra
#

(Back) I mean so is setting up a module when you start from scratch entirely. This is why you copy over previous work that you like.

vast latch
#

We're getting a bit off topic but there are module agnostic ways of doing it

supple raven
#

ngl, if yall arguing about convenience you want the current hotreload feature. It's 2 lines in a json file.

lapis spoke
#

As for hot reload not working for popouts, I wouldn't care it not working with those.

supple raven
#

fr, would rather have HR with some limitations than no HR at all

cunning belfry
#

When they say "In exchange for abandoning this feature, we would be able to invest a significant amount of developer time (probably about 2 dev weeks) ..." is it sensible to reframe the question as "would you rather have hot reloading or have V14 arrive half a month earlier"?

desert rune
#

If you have 4 dev in your team, 2 dev weeks only delay by one half of a week.

final crystal
rocky umbra
#

-# Something something "9 women can't make a baby in 1 month"

versed meadow
#

Yeah, quadrupling the devs working on a thing makes it take somewhere from 80% to 150% of the initial duration (depending on the task and devs)

rigid panther
#

Removing reloading will make my developments more complicated and painful. I develop premium modules, and the css formatting phase requires a lot of reloading.
At least, keep the css hot reloading (and keys translation).

torn granite
#

@final crystal Can the choices get a little more nuanced? It would be nice to be voting not only on whether there is hot reload at all, but making hot reload of CSS specifically a separate matter (as most things about CSS are often a separate matter from HTML or JS.) It would also be nice if the question clearly enumerated what kind of things hot load currently supports today (so we know what precisely is on the chopping block.)

prime wing
#

The CSS and Template hot reloading has become almost essential for me (and has likely extended the life of my F5 key)

errant storm
#

Yeah, I believe most of the "Essential" votes are mostly for the CSS

spare briar
#

fwiw, all 3 elements are time savers for me -- CSS, HBS, i18n

final crystal
#

I'm honestly surprised that (response bias aside) over 50% of responding devs use hot reload in some capacity. I would have guessed a much smaller number.

errant storm
# spare briar fwiw, all 3 elements are time savers for me -- CSS, HBS, i18n

fair, but HBS and i18n don't bother me much. i18n especially, I don't really need to see changes in real time, it doesn't impact other areas.
With HBS, while I do enjoy it sometimes hot reloading (sometimes it doeesn't), it often is accompanied with JS changes so reaload is still needed, so lack of that part of HR wouldn't bother me that much.
But lack of CSS HR would be biggest hit on me, as I am not good enough with CSS to be able to make some changes in CSS and immediately know full picture of how they look, or to have outcome in mind and be able to nail it every single time. I still do require trial&error with CSS, and HR saved me tons of time in that department.

If not for the CSS part I would vote "Not Essential"

final crystal
#

unless some people are voting "Aware + Not Essential" when they should have voted "Aware + Not Used"

spare briar
torn granite
#

Looking at the tickets, the only ones that raise any concern for me are #11762 - since that is becoming an essential feature of i18n - and #9968, although my response for 9958 tends to run toward “if you want hot reload, don’t do that - or use Vite for reload, which knows about the load context of JS modules.”

errant storm
prime wing
#

I mean, I can only speak from a personal point of view, but for me hot reload is way more important than an Application pop-out feature (which I'll likely never use TBH)

versed meadow
marsh oracle
#

(It's also worth highlighting that there's also the bias of "people who would be aware hot reload was even an option", given how hidden it is)

supple raven
tropic goblet
#

Honestly, for me, CSS is the least important part, since it's the easiest to work around for me. There's vite which already handles it for my systems and for my modules, I could just edit in firefox devtools. Not to say that it's not important, but losing i18n and hbs hot reload would be harder to replace in my workflow.

errant storm
spare briar
#

(bias conjecture is biased conjecture)

agile edge
#

I haven't read all of the messages in here so I have no idea where the discussion has gone so far, so pardon if I'm repeating anything already said.

The way I personally use hot reloading is a listener on the hook that manage my own hot reload methods (for JS/CSS, I just make the page reload entirely, but for SVG I fire off a custom hook for my web components to dynamically update without reloading the page, so I would personally be fine with all of the core hot reload stuff being yeeted, though keeping the hook around just to handle custom hot reloads without something like Vite would be nice in my opinion, that way either a module could provide hot reload where it can for more files, or each dev can roll their own if/as desired.

TLDR; I like having hot reload, but would be perfectly okay if it was entirely removed from core

prime wing
desert rune
# final crystal We would not have all 5 devs working on hot reload, so it would be single thread...

Yes, but even if you "only" tack one of the dev on this, the other still produce on the other things. Unless the deadline for everything is in less than two week, it will not increase the project timeline for more than the task duration divided by the number of full time humans.

Something something "9 women can't make a baby in 1 month"
The "9 women 1 month baby" thing only stand when the only task (or so) is the baby. If you need more than 9 babies, the computation is valid and usefull for deadline estimation. In our specific case, I would be surprised if the total dev time for the v14 were not larger with at least one order of magnitude than these features.

supple raven
#

seems irrelevant.

lapis spoke
#

Kinda sad only quarter seems to want to keep the feature.

prime wing
#

I wonder how many of the Aware + Not Essential crowd have actually used it? Because then they might change their minds...

agile edge
#

I voted for Aware + Not Essential and I use hot reload on literally all of my Foundry projects, I find it useful, but it's not IMO the end of the world if it gets removed, I'd like the hook to stay so I can roll my own HMR, but that's all I really want, and even then if Foundry removed the hook I'd be a bit sad but it would still be fine.

rocky umbra
#

Same, the only loss would really come from i18n being auto-refreshed across Foundry apps while I use Vite for everything else.

final crystal
#

Everyone who says "the only thing that really matters is {X}" has a different {X} 😉

cunning flare
#

Such is the nature of life.

outer saddle
#

As has been mentioned i18n / json hot reload is quite nice and would be great to keep. In my framework its seamless and easy to enable and quite nice to dynamically alter lang files and just see the text appear instantly. Behind the scene I handle the hooks from Foundry and do the reloading / built into framework (it's only included when running the Vite dev server), so no end dev setup other than the manifest additions / turning it on for the server. Svelte / Vite handles everything inside components already (very neat) and Vauxs has posted examples of using the Vite HMR API for JS.

spare briar
#

I took kind of the opposite approach and built a rollup plugin to be compatible with/take advantage of foundry's CSS/HBS/i18n hot reloading. So its loss would kill all of it for me.

green vine
fickle glen
#

My vote is that it'll slow things down for me, but it's not the end of the world. I did without it (not knowing it was there) for a long time. My order of priority (if such a thing is possible):
localization > hbs > css > js

errant storm
#

I wonder why HR for localization is such high priority for people.. am I missing something? 🤔

versed meadow
#

It does feel weird to me too, since I just write the localization keys once and I'm done, but I suppose someone doing a translation module or whatever other project with a lot of keys scattered around would benefit from seeing live changes

errant storm
#

right, I can see that

supple raven
#

I have a general structure for all my i18n, and I write the keys in hbs first. That way it's easier to see later when filling out the keys in your lang file what's missing, and hotreload of hbs helps with that

#

(It's also just satisfying.)

prime wing
#

css > hbs > i18n > js for me

outer saddle
#

Low hanging fruit (i18n / lang / json). I haven't looked at the backend code, but that probably is the least invasive / difficult to maintain.

So, hot reload of lang keys is neat because you can use it and add new keys to the lang file as you are going and add them into UI code and it works seamlessly. And indeed the localization part if supporting lots of languages it is handy.

I can see where hot reload as implemented in FVTT for hbs can cause a maintenance burden in respect to AppV2 / partial rendering. Also limiting aspects of having to ship that code to the client all the time.

As far as future v14 Popout support concerns hot reload. I see no problems in clearly stating in any dev docs that it won't work in this case. Hot reload just being a dev convenience if still supported for in main browser window dev only.

versed meadow
#

Thinking about it, I feel like localization hot-reload implicitly requires HBS hot-reload too, because the localization keys are getting used in Handlebars templates. I think CSS is the only one that can really be separated from the rest

errant storm
#

Agree, my assumption is that popped out apps will for us (devs) be basically the exact same thing as standard apps, so there is no reason to dev while using popout. So I don't think HR needs to work with that, I would rather it existed and worked well for main window

outer saddle
marsh oracle
outer saddle
#

Yeah.. I was going to say... I gather that is the approach for hbs, etc. My efforts work a bit differently as there is some Svelte internal handholding involved when bridging between the FVTT hot reload callbacks.

marsh oracle
#

the only difference for hbs vs. json is the pre-handling (update registered hbs templtaes vs. update game.i18n.translations)

    for ( const appV1 of Object.values(ui.windows) ) appV1.render();
    for ( const appV2 of foundry.applications.instances.values() ) appV2.render();
#

(this is from the Game class)

tidal aspen
#

I think the most overall annoying part of the dev experience without hot reload would be to loose the context of what ever you are working on. Having to click through to the menu you were debugging every time you change code.

ember flint
#

As someone who hasn't set HR up that's the pain point that's made me think about using it in the past

jade loom
#

I would be happy if we can keep the hook and the watcher. Then we can reimplement it ourselves

errant storm
#

I mean, if the socket remains and all we need is to reimplement 3 short methods, that would still be good

fathom apex
#

a reason to revive the old Developer Mode module to do that

final crystal
# final crystal
poll_question_text

What single response best describes your usage of hot reload?

victor_answer_votes

57

total_votes

193

victor_answer_id

1

victor_answer_text

Aware + Essential

#

Interesting results and discussion. I'll find some time to discuss this with the team and we'll follow up to let everyone know what outcome to expect in v14.

final crystal
#

Hello @here, following up after this poll and time for us to internally discuss. We've made a decision about what we're doing with Hot Reload in V14.

  • We are not going to remove hot reload, as it's clear that this feature is important and valuable for many of you. Thank you for the feedback that helped make that clear.
  • We are going to remove support for hot reload of Javascript files. JS hot-reload does not currently work reliably and would require an unreasonable investment of effort to try and perfect.
  • Hot reload will remain a feature for CSS, HBS, and JSON localization files, along with some improvements to make reloading of those types of files more reliable
  • We triaged existing hot reload issues and identified several that we will fix during the v14 development cycle, but also closed several that we wont fix.

You can see the outcomes of that triage here: https://github.com/foundryvtt/foundryvtt/issues/13285

Thanks for your feedback and we hope that this compromise leaves most (if not all) of you feeling good about the outcome.

GitHub
Assorted Hot Reload improvements for Version 14 - including some re...

This issue is not "epic" in size, but tagged as "epic" because it aggregates a variety of assorted hot-reload related changes. Will Remove #13284 Will Fix #9958 #9951 #9100 #995...

supple raven
#

Sounds great to me tbh. Didn't even know HR worked for JS, reliably or not.

#

One question though:
If a module that makes use of hot reload is not active, but then activated via the module manager, hot-reload does not function until a return to Setup. Is that a known issue and/or does it fall under #11960?

final crystal
supple raven