This chapter is about setting things up. The tutorial uses Python and libtcod. I’m using Javascript and ROT.js.
I’m using Javascript, with Typescript to show possible type errors in the IDE. This gives me soft type checking, completions, some type error detection, but doesn’t require that everything be type annotated. And it doesn’t require a build step, which is important to me.
I’m using ROT.js. I “bundled” it into a single module with type definitions. The project[3] offers several options but I wanted a fourth:
| Option | Type checking? | Modules? | Bundled? | Build step? |
|---|---|---|---|---|
lib/ |
✅ yes | ✅ yes | ❌ no | ✅ no |
| bundled | ✅ yes | ✅ yes | ✅ yes | ❌ yes |
| prebuilt | ❌ no | ❌ no | ✅ yes | ✅ no |
| my config[4] | ✅ yes | ✅ yes | ✅ yes | ✅ no |
[And no, I didn’t write this page with an LLM. I actually pasted those characters int the table myself.]
I also added the copyright notice to the bundle, which is required by the BSD-3-Clause license.
I’m using Jujutsu on top of Git, so I ran jj git init instead of the usual git init. I learned about Jujutsu by reading Steve Klabnik’s page[5], Stavros’s blog post[6], Jimmy Koppel’s workshop[7], and Justin Pombrio’s cheat sheet[8]. I’m using the Majutsu interface[9].
Jujutsu maintains a “change ID” and also a “commit hash” (from Git). If you edit a change, the change ID stays the same, but the commit hash changes. My goal is to use the change IDs to reflect the parts of the Roguelike Tutorial, and the commit hashes to reflect the timeline. More on this later.
As an example of the kinds of things I am doing with Jujutsu, I had originally used the lib/ version of ROT.js, but I went back and changed it several weeks later. With Jujutsu, I changed it in part 0 and propagated the change forwards to all the later parts of the tutorial. That’s … weird. I erased the history of what I actually did and replaced it a cleaner version. The alternative is to make the change partway through the project, which is what the tutorial page does. They do things one way, then change it partway through, and then say:
After parts 1-5 for this tutorial were written, we decided to change a few things around, to hopefully make the codebase a bit cleaner and easier to extend in the future. Unfortunately, this means that code written in previous parts now has to be modified.
I have mixed feelings about this. On one hand, it’s good to see that other people have to change things too. But on the other hand, I am often frustrated by this in tutorials. “Why did you make me do things one way if it’s not the right way?”
Since I’m learning Jujutsu, I decided to embrace the “rewrite history” feature. I learn faster by trying things I distrust to gain actual experience. My alternative was to judge it without using it fully. I used it often, and have lots of thoughts, which I’ll write up later.
Normally Jujutsu won’t let you rewrite history after you push to GitHub. I decided I wanted to rewrite any code any time in this project, so I configured Jujutsu: