I recently discovered that Amazon's Open Source contribution policy had gotten even more streamlined, allowing engineers to make simple contributions to most projects without pre-approval. It was never fun having friction that was potentially more work than the small fix you wanted to upstream, and so I'm really excited about this. I'm always happy to make PRs and always feel a little sad when I have to break out the old patch-package hammer, so now I'll be able to quickly pull down a repo and contribute a quick fix. Even better, it's always enlightening to see other repos and setups and patterns, providing a great learning opportunity. With all that in mind, this policy update prompted to consider what contributions I had made the effort to push through the process.

DefinitelyTyped

Like anyone using TypeScript, I've relied heavily on the awesome DefinitelyTyped project for any project, professional or personal. I'd been playing around with TS on the side early on, and getting to use it at work was one of the that appealed about the opporunity at Twitch. TypeScript 2.0 had just come out, and it's reworking of type acquisition made things vastly simpler (no longer did people have to learn about "ambient" type declarations, etc), the tipping point for what became huge momentum within the JavaScript world. The DT types are incredibly polished now, but early on they were understandably missing some things, and I stumbled into that with some testing libraries (who would've guessed these were the under-loved ones initially 😛) as I jumped into my new work. This resulted in really needing filled out type definitions for expect and fetch-mock, and so these were made within my first 2 weeks and where when I learned about the old policy. Later on as I helped with the styled-components conversion of our UI component library, I quickly ran into a type limitation that required an update to support the push for more semantic HTML usage. DT contributions are usually pretty straightforward, and as a bit of a type nerd, I'm looking forward to doing more.

react-spinkit

Before Twitch had a proper React UI component library, things were less standardized, especially in our scrappy mobile web project. As we converted into a true SPA we started needing loading indicators, and react-spinkit was the de facto choice at the time. We'd run into issues trying to use it in an SSR application, and so I got approval and wandered in hoping to make a quick change. Along the way I noticed some other small papercuts and starting pulling on some threads, and before long I wound up with a massive update that made a lot of changes, modernized some of the patterns (per the long-ago days of 2017 at least), closed 6 diverse issues, and resulted in a major version bump. Ironically, we actually wound up getting an official replacement a few months later. But looking back at that library, I'm kind of curious about doing a 2021 update pass based on everything I've learned since then and to see what I think of how I left things before.

Workbox

Workbox serves as the foundation for many service worker implementations, and we began experimenting with one to further improve our SSR app's performance. But we wanted to keep leveraging our cached SSR pages so we needed to use the rarer navigationPreload functionality, but it wasn't plumbed through all the wrapping libraries. I thought it was going to be a simple change but Workbox is a complex monorepo, which I was luckily already familiar with at least. The eventual final PR involved one line of new actual logic, plumbing the value through a few layers, and then mostly updating their extensive test suite (which was really cool and invoked all the browsers on my computer for true integration tests). Sadly, I stepped into one of the few untested areas as well and had to do an immediate follow-up 🤦. This contribution meant I needed paperwork with both my company and Google due to their CLA, but it's always fun adding something to these big important libraries (which was I jumped on this one as soon as it came up).

Relay

On the topic of adding to big libraries, my contribution to Relay was easily the funniest. It was definitely more paperwork (including another CLA) than actual work, since all I needed to do was run a script to generate a new version of their Relay Specification site, which I needed to help show our GraphQL team how Relay's expectations differed from base GraphQL. Their docs CI job was broken and I was tired of explaining why the published site was out of date, so I wound up with an unglamourous contribution that looks much more impressive on paper.

Looking over that list, after the initial first-month work, we really leaned on filing issues and hoping or using patch-package unless there were issues that spread outside of our team and thus couldn't be as efficiently worked around. Going forward, here's hoping the tides are changing.

Update One Week Later

Things are off to a good start, with PRs to both type-fest and relay-compiler-language-typescript. In fitting with my above comment, these were both nifty type-focused changes and I really enjoyed them.