The End of expo-community-flipper

[thecodedrift]

---
slug: expo-community-flipper-retired
published: 2023-08-04T18:19:00-07:00
description: Thoughts on "completing" an open source project
excerpt: That moment when you're comfortable putting a temporary project to rest.
changelog: ~
---

With the release of Expo 48, expo-community-flipper (gh)[https://github.com/jakobo/expo-community-flipper] (npm)[https://www.npmjs.com/package/expo-community-flipper] can finally declare its purpose fulfilled. A year ago, I was trying to debug redux inside of the Chrome Debugger and nearly lost my mind. It wasn't just a bad experience. It was an awful experience, defined by console.log and prayers.

There was react-native debugger and reactotron, but nothing that worked for me specifically. My setup was weird but not unlikely. WSL2, Windows 11, and the iOS app running via Expo's custom dev app. Only one thing really worked with this setup, and that was Flipper. Plus, I could finally see FPS information for animations as an added bonus (more on that later).

Expo & Flipper in a Graph

One of the problems with using Flipper was that it required editing the Podfile. This is all well and good if you're using react-native on a mac and love running XCode yourself. But if you're that weird-dev-guy with WSL 2, running XCode is impossible legally troublesome at best. As a lucky coincidence, Expo pushed out SDK 43 and began documenting their config plugin system: scriptable JavaScript that could edit & change build files as part of a remote CI or build pipeline.

And so, starting with SDK 43, I released the first version of expo-community-flipper on npm into the wild. With every subsequent SDK, I'd check the expo base template and the React Native Upgrade Helper and focus on changes to the Podfile.

It was a scramble. It wasn't always obvious what changed. Sometimes a random AppDelegate.m was the culprit, other times it was the ruby scripts to include Flipper upstream in the React Native libraries. It got better though with every release.

• I wrote a post for the Expo team to go along with my WSL 2 article I did earlier for them
• Alexandre Moureaux hooked performance monitoring in and gave a talk
• Abdulrahman wrote an article

Debugging was finally easier. It would just be nice to get out of reaction-mode when new SDKs were imminent.

Enter the Expo Team and Merging Up

SDK 47 marked the beginning of the end in a positive way. There were changes coming that would break expo-community-flipper, and the expo team wanted to be proactive about the changeset. This was the first time in the project's history that expo-community-flipper was going to be SDK ready on launch. This proactive outreach got the wheels turning though. What if expo just did the "Flipper bits" itself? They've got a much better testing suite, there are already plugins for modifying the Podfile, and then Flipper could get the attention it deserved.

Ideally, SDK 47 would be the last time we'd have to do this npm release dance. After talking with the Expo team, we launched a plan to merge expo-community-flipper upstream into the build-properties plugin. It landed in January and Flipper support became an official part of the expo-config-build-properties plugin in SDK 48.

This section is pretty uneventful because the Expo team is just that good. I worked with Kudo Chien for most of the PR and integration, and Expo had the infrastructure to absorb the changeset without issue. I was honestly impressed at how smooth everything went. I also like the "Why" and "How" sections they encourage on PRs for explaining their changes.

Ending expo-community-flipper

Finally came the goodbyes. A README change, a release on SDK 48 with a peerDependency that keeps it from running against newer Expo versions, and an npm deprecate. And it was done. With Expo SDK 49 released and deprecating 46, and SDK 50 on the horizon, expo-community-flipper will be finally be archived and the project complete.

It's surreal. It feels good. Not many open source projects get a happily ever after.