In this sprint, I shifted my focus from Hurl to Starchart. Spoiler alert: Lots of dependencies were involved 👀.
🦀 Hurl
I didn’t make much progress on Hurl this week. However, I did finish the requested changes for my previous PR, which involved adjusting some error handling rules. It wasn’t anything groundbreaking, but I did learn a few new tricks from clippy:
I encountered the errors above after applying a suggestion from the maintainer:
let is_ipv4 = IpAddr::from_str(&value).map_or(false, |ip| ip.is_ipv4())
The goal was to ensure is_ipv4 is true only if the parse result is OK() and the parsed IP address is IPv4. Since we’re dealing with booleans here, clippy suggested using .is_ok_and:
let is_ipv4 = IpAddr::from_str(value).is_ok_and(|ip| ip.is_ipv4());
This accomplishes the same result but makes the code much more readable!
Concern for the Future
I saw a comment from the Hurl maintainer that they are pausing contributor pull requests. Since Hurl is my 80% project, I’m wondering what this means. Should I focus more on Starchart, or perhaps look for something else for the time being?
📃 Starchart
Code Reviews
It was more difficult than I expected—not in terms of technicality, but because I’m still unfamiliar with reviewing code in a new project. I tried to stick to this guide that was shared with us last semester.
Update Remix to v2 #833
At first, I was completely lost. There were random changes all over the place. But by reviewing the commits one at a time, I realized that most of the changes came from a migration tool. I compared them with the PR description, and everything seemed to be in order.
Bump Prisma to 4.16.2 to match @prisma/client #831
It was a simple version bump. However, during the review, I went to Prisma's documentation and found that the cli tool should be installed as a development dependency, which was a helpful discovery.
Add ESLint 9 to support oxlint #834
Since I worked on the same code previously to remove ESLint, it wasn’t too challenging. However, this PR added even more ignore configs than what we already had. So, I asked the author if there was a way to consolidate them into a single source.
Update Dependencies - Part 1 (Link)
In this PR, I used npm-check-updates to update packages with minor version bumps. Expecting no breaking changes, I upgraded everything at once. Of course, it broke 😆. The issue was I couldn’t pinpoint which package caused the problem.
I reverted my changes and applied the updates one by one. Eventually, I discovered that the culprit was samlify. It was surprising, considering it was just a minor version bump from 2.8.10 to 2.8.11. I checked the changelog but couldn’t find any relevant information, so I decided to exclude it from this PR.
Update Dependencies - Part 2 (Link)
Learning from my previous mistake, I upgraded one package at a time in this round. Since I was dealing with major version updates, I made sure to check the changelog beforehand.
I encountered only two breaking changes: For husky, I found a migration guide in the release notes. For isbot, they also outlined the breaking changes. Both were simple syntax adjustments, nothing too complex.
I also got stuck with prisma. Every time I updated it, the project would break and throw errors. Some quick research revealed that I needed to run prisma generate each time I changed versions.
Results
After the two rounds of updates, the list of outdated packages looked much cleaner:
| Before | After |
|---|---|
 |
 |
As for the breaking packages, I created an issue to track them.
🤔 Some Thoughts on Dependencies
I had a chat with Uday recently, and he voiced a concern that we’re spending too much time on dependency updates.
And he’s right. We’ve been going back and forth on dependencies for quite a while now: discussing whether we should maintain certain dependencies out of frustration, dealing with dependencies that randomly break things with unclear changelog documentation, and handling unmerged dependency updates that block further updates or new features...
Does managing dependencies really take this much time? Is it just because we were assigned to an outdated project? Is there a better way to handle dependencies so we don’t have to fight with them so much?
Top comments (0)