Rest & Recovery 5e
Just creating a forum post to chat about upgrading the Rest & Recovery 5e module to the latest TRL and future integration aspects w/ Tidy Sheets 5e. @Michael
14 Replies
Many thanks
Luckily I don't recall this module being too intense in what it does, so getting things upgraded shouldn't be too much trouble.
Yeah, it's fairly basic in terms of UI, most of the more complicated bits (which, even those aren't terribly complicated) are behind the scenes
I gather some of the sticky bits may be related to any compatibility aspects with the latest 5e system updates then any aspects related to the Tidy sheet integration.
That's the main reason it needed taking over; it wasn't compatible with 3.x in a couple spots. I've noticed while making it compatible with Tidy5e that it's actually not compatible with the "New" 5e actor sheet where it injects html. But I'd imagine the only real issues with upgrading TRL would be any breaking changes on functions that are already being used
There may be very small breaking changes in the very latest
0.2.0
TRL release that is imminent, but probably nothing in particular otherwise.
Some of the main difficulties is that the codebase is not commented and there may be some bespoke ways of handling various things that Wasp created where there may be more streamlined solutions in TRL. Basically challenges related to taking over a codebase one didn't create.Right. I haven't done a full go-through of it all yet, mainly just fixing the areas in need of fixing
An example of bespoke Foundry integration seems to be the settings code.
I am busy for most of this weekend, so will likely have more time mid-week next week to help.
Sure, no rush! Will be nice to clean it up a bit, but nothing's breaking yet (🤞)
Plus it'll give me some time to familiarize myself with the docs
A challenge in that regard is that the
0.1.0
release is when the docs first became available and there was a lot of internal restructuring. For the most part I gather things will line up with the current code base. When you view the API docs #runtime
refers to @typhonjs-fvtt/runtime/
. I didn't see anything in particular being used from the #standard
library which is an additional library of components and such.
TRL uses many Node / NPM sub-path exports for the library grouping code logically more like say the Java runtime / standard library than from many independent packages.Gotcha, will keep that in mind
Think I might give updating to a more recent TyphonJS today or tomorrow. Wanna get that stable and working in v11, dnd5e 3.1.2 before I start trying to account for v12 and 3.2
@TyphonJS (Michael) Alright, I believe (I haven't done a ton of testing) I've got it working with 0.1.3, and svelte 4.2.17 (just based on what my package-lock is telling me - I just said
^0.1.0
and ^4.0.0
respectively). Besides running the svelte migration script (which didn't actually need to change anything), and ignoring automatic devDependencies version increases, here are the only changes I had to make to achieve the same functionality:
- @typhonjs-fvtt/runtime
-> #runtime
in all imports
- Sometimes I'd have @typhonjs-fvtt/runtime/_dist/.../index.js
, replaced those (example: import { localize } from "@typhonjs-fvtt/runtime/_dist/svelte/helper/index.js"
becomes import { localize } from "#runtime/svelte/helper"
)
- One import changed path (TJSDocument
went from just svelte/store
to svelte/store/fvtt/document
)
If you can think of anything else obvious that I'd have missed and not been able to tell without more extensive testing, let me know! And then I can start to figure out how to better leverage TRL in the areas where I should beNot having looked through the R&R package code much if you got things compiling / running then you got the essential changes from the older TRL release (
0.0.20
-> 0.1.3
) handled. The import and IDE confusion over package paths is certainly something that IDEs will likely get better with over time; I use WebStorm and it doesn't work 100% in that capacity yet in respect to using imports
in package.json
to remap package paths.
Things to consider. Wasp is a talented developer, but some of the modules like R&R were smaller one off projects and at the time it was created API discovery for TRL still wasn't as easy. There are several things in R&R that are bespoke solutions implemented at that time.
I think in the short term getting things working and integrated in the capacity that you'd like w/ Tidy 5e sheets is a good goal. Reworking the rest of the module to leverage more standard solutions of TRL can come in time. Perhaps in a push to get everything updated for the upcoming 0.2.0
release. I'll be setting aside some time to help folks get through that migration.Great, thanks. I'm in agreement: Everything seems to be working now, so I'm happy. I'd like to, as you mentioned, eventually move away from the bespoke elements (specifically I think the way settings are handled), but since right now I'm hitting full compatibility (as far as I can tell) in V11, V12, dnd5e 3.1.2 & dnd5e 3.2.0, those changes can wait
Absolutely re:
specifically I think the way settings are handled
as that is one thing that immediately stood out.