Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

I've made TypeScript type declarations for the Roll20 worker functions (and converted my sheet worker to TS).

The Stars Without Number: Revised sheet has, for a long time, been written in Pug/Sass. This already required a NodeJS install and a couple of global packages. Today, I decided to improve my situation. A quick `npm init` and some faff later, and I now have a package.json to manage those couple of dependencies. Bonus: it's easier to install on a new machine/for new people. Just `npm install && npm run dev` and everything is running and compiling! Tsc compiles the ts first, then Pug notices that the workers.js file changed and recompiles. Now for the title: Converting the worker to TypeScript. TS comes in a handy npm package, so everything above still applies. However, I needed some type declarations for all the global-scope functions Roll20 exposes. So I sat down and wrote some. Here they are. I used the documentation on the wiki (which, admittedly, doesn't say anything about types) and went from there. All the sheet attributes are stored as strings, so getAttrs will give you that, but setAttrs can take a variety of types that get coerced/converted to strings, so I put some other types in as well. It might not be fully exhaustive? Maybe they'll be useful to someone else. My sheet is now successfully running in TS! (and I already found a number of probably subtle bugs that I would have struggled to find otherwise). All in all it went surprisingly easily, and gave me the opportunity to clean up some seriously bad code.
1613864864

Edited 1613864900
vÍnce
Pro
Sheet Author
Hi Karl, very interesting.  The PF Community sheet was setup similarly 4+ years ago...  IME there may be great benefit/efficiency gained by creating a custom environment for complex sheets but it can likewise be a major deterrent for us "non-programmers" from contributing. ;-(
I definitely hear ya on the deterrent point. I was once a "non-programmer" myself, and I remember being stumped when I first went in to update the old Stars Without Number sheet for the Revised edition of the rules. It can be a bit of a one-two punch to go "oh and by the way, you also need to set up this thing and learn these completely different syntaxes". I do think it's worth it though, at least on sheets with active maintainers. The amount of work I've saved by not having to change the same thing on every skill in the skill list by hand (and other similar benefits) is substantial. Being able to reuse parts of the interface is a major benefit. Today's changes were mostly a streamlining of the existing setup, however. With the exception of TypeScript, which is definitely a change for the more intimidating I admit, putting it all into a package.json file should make it a fair bit easier than it was at least, as everything is just a bit more automated to set up. I wasn't aware of the Pathfinder sheet having done similar before. I have a sort of long-standing frustration with the inability to use modern tools on Roll20 (and the design of the character sheet API in general, which has a very "we made this before Promises and async/await" vibe to it) , and this was one more step I could take to make my life easier. My next "project" I've been kicking around is to find some way to write automated tests. I'd love to be able to have confidence that my sheet still works without having to test every single little feature manually every time I change something, but the details of how I would mock the API without spending too much time essentially rebuilding it have yet to settle.