destroytoday.com

Tidying up as you go

I’m still inching along towards making the invoice page SCA-ready by removing the legacy Stripe Checkout and integrating Stripe Elements. In the process, I’ve also been updating other aspects of the invoice page, so I’m “renovating” more than simply bringing one part “up to code”. I’ve noticed recently that I can’t help myself from doing that—it’s also how I am at home. If I’m heading to the kitchen, I might as well look for what I could bring with me as a way of tidying up as I go.

lite

The “Secondary Bar” in Cushion’s “Lite” component library

For the invoice page, so far, this has been somewhat more significant than bringing a couple glasses to the sink. I’m implementing my new component library (named “Lite” for no real reason), but I definitely don’t want to continue the existing approach of having a component repo that I install as a package. That forces me to commit to the component repo when I need to tweak a component, then pull from the invoice repo, which is a hassle and nonsensical for a one-person team. Instead, I’m aiming to move everything into a monorepo (a single repo to house all the code), which might seem backwards for some folks, but at Cushion’s small scale, it’s silly to separate the code.

I wish moving to a monorepo simply meant dragging all of the folders into one and calling it a day, but the migration requires so much more than that. In fact, it’ll be such a rabbit hole that I’ve started to emulate the result before actually doing it. (This is either brilliant or idiotic—I’ll let you decide.) In order to use the new components in the invoice page, I set up a process using rsync that watches the component directory and syncs any changes into a subdirectory within the invoice repo. This does mean the component code lives in both locations, but it emulates what the monorepo will be like when it’s fully migrated. In setting it up this way, when the rest of the repos are ready to merge, I should be able to simply copy the folders over. (This is only possible—and should only be done—if you are a one person team)

Another “chore“ I’ve baked into the invoice page work is adding SSL to Cushion’s local dev environment, so all the URLs could start with “https”, which is more inline with production. I always assumed this wasn’t possible until I actually searched for a solution, which led me to mkcert. Using this package, securing your local dev server is a matter of running:

mkcert -install

Then running…

mkcert example.com "*.example.com" example.test localhost 127.0.0.1 ::1

…but using your own host names. This will leave you with a cert and a key, which you can point your local servers to. Each server goes about this differently, so I’ll leave that to you to figure out, but it works! Having SSL on Cushion’s local servers feels surreal after blindly living with the inconsistency of “http” on dev and “https” on prod. This is one of those implementations where it feels right once you’ve done it.

I’m very close to wrapping up the invoice page, and while these chores along the way are definitely slowing the progress of my main goal, they’re saving Future Jonnie lots of time and frustration. As much as I enjoy improving Cushion as a user-facing product and business, even more so I love making it the best possible codebase to work in. That’s what will keep me going for years, if not decades, rather than the app itself feeling like a chore.