This post is for Day 5 of Mercari Advent Calendar 2023, brought to you by @adbutterfield from the Mercari Web Architect Team.
Hello, everyone! As winter rolls in with its festive cheer, and we’re all buzzing with the holiday spirit, here at Mercari, we’re unwrapping our own unique kind of presents: our open source contributions.
Let’s think of open source like the world’s biggest potluck dinner, where we’re all bringing a dish, a tweak, even just a pinch of salt to the table. That’s the beauty of this community – every contribution, no matter how small, adds flavor, fixes a bug, or makes a software run a bit smoother. And just like when you bake cookies to share at a holiday party, these little acts of giving warm up this grand techno-feast!
This is exactly what we’ve loved doing this past year: adding our ingredients to the open source potluck. Our recent journey taught us that sometimes, it’s the little things, the small acts of giving, that truly matter.
As part of our delightful December Advent Calendar series, get ready for a fun-filled trip down memory lane, uncovering the nuggets of code we’ve shared, the tech-tangles we’ve solved, and the big difference our seemingly small contributions have made in the amazing world of open source.
Eluding ESlint Hiccups with SSR-friendly Contributions: eslint-plugin-ssr-friendly
Contribution: https://github.com/kopiro/eslint-plugin-ssr-friendly/releases/tag/v1.3.0
You know the saying: "It takes a village to raise a child"? Well, we like to think of our coding community as a village, brainstorming, debugging, and enhancing open source "offspring" to help them reach their full potential. One such prodigy that we’ve nurtured is the existing eslint-plugin-ssr-friendly.
A hitch we bumped into was a bug pestering us about using browser globals on an SSR application. The eslint-plugin-ssr-friendly was good at catching the wrongdoers, but there were a couple of crafty bugs it didn’t recognize. So, we thought, "Time to upgrade this plugin, make it even better!"
We decided to trial it by intentionally throwing in some violations to see if the plugin would identify them. Lo and behold, a couple of these violators didn’t get detected! We created a few issues and dialed down into the source code to fix ‘em up ourselves. And let’s be honest, having never modified an eslint plugin before, it felt like solving a puzzle in zero-gravity.
A little disoriented, but unfazed, we teamed up with our secure, internal coding elf, aka ChatGPT, to crack this nut. With her guidance, we navigated through the testing framework, added the missing rules, and like the hero in a holiday movie, saved the day!
Now, our improved eslint-plugin-ssr-friendly is ready to serve not just us, but the entire JS community with even fewer SSR-bug-related headaches. It’s like we’ve added more holiday lights to it, illuminating the path for everyone, and most importantly, keeping the spirit of community giving alive!
Daring Detours with Detox – Enhancing Accessibility Actions: Detox
Contribution: https://github.com/wix/Detox/releases/tag/20.8.0
Here’s another tale from the tech trenches. Our adventures this time led us to wrestle with e2e tests on our app using Detox. Now, don’t get us wrong – Detox is a great tool, but we found ourselves wanting just a touch extra – a way to conduct accessibility actions within the app. This missing trick in the Detox playbook made it challenging to fully test our snazzy AttributedString components and overall accessibility.
So, what do we do when we encounter a bump on the tech road? Strap ourselves in for a learning curve rollercoaster! Diving deep into the machinery of Detox, understanding its idiosyncrasies across mobile platforms, we were like video game characters figuring out the hidden rules for a bonus level.
After several rounds of brainstorming, coding, and caffeinating, we managed to score the winning goal. We added the performAccessibilityAction action to the Detox API. This was like finding the missing piece of a jigsaw puzzle, enabling us now to execute accessibility actions on both iOS and Android within React Native.
With this fun addition to Detox, it feels like we just leveled up! Not just for us, but for everyone out there using Detox for e2e tests. Proof that no contribution is ever too small in the open source universe. Here’s to making the tech world more accessible, one code upgrade at a time!
Bolstering Babel with Enhanced Language Compatibility: babel-plugin-i18next-extract
Contribution: https://github.com/gilbsgilbs/babel-plugin-i18next-extract/releases/tag/releases%2F0.9.1
Imagine you’re gearing up for a major global tour (or in our world, adding an additional supported language). You’ve packed your bags, revised your itineraries, hired a competent tour guide (or in our language, relied on babel-plugin-i18next-extract to juggle with the translation keys). You’re all set to explore, when boom! You find out your "passport" is invalid – your perfectly acceptable lang-region format tag causes the command line interface to give a bewildering error – Unknown locale ‘en-US’.
Time to put on our detective hats again!
We discovered that the culprit, Intl.PluralRules.prototype.resolvedOptions(), wasn’t recognizing the correct locale. It was like someone trying to navigate New York using a map of London. For example, for en-US or en-UK, it was only giving us back en, causing our program to throw an error since en is definitely not equal to en-US or en-UK. All this happened despite the Intl specification clearly stating that the returned locale should match the BCP 47 language tag, and not chop off the region part.
Interestingly, we found different environments, like chromium based browsers, Firefox, even Node, gave differing outputs when we ran it with Intl.PluralRules.prototype.resolvedOptions(). Thought you were just adding languages? Welcome to the world of tech, where you encounter a whole new city of mysteries!
Our approach to fixing it was simple: just check if the tour pass (en-US) included the map (en). We came up with a solid workaround, but here’s hoping that Señor Intl will fix its GPS soon and align the formats for a smoother ride. Until then, our solution is out there, brightening the babel-plugin-i18next-extract landscape, and making sure that more languages and places get visited without a hitch. Another tiny gift in the open source chronicles!
Bringing More Sparkle to Ky – Making HTTP Client More Robust: ky
Contribution: https://github.com/sindresorhus/ky/pull/533
Let’s ring in another tech story, this time starring the simple yet powerful HTTP client Ky. We hopped on the Ky bandwagon when migrating to a fetch based HTTP system for web apps, thrilled that fetch was finally stable in Node 21+! But the excitement was tinged with a bit of blue when we realized Ky could do with a little tinkering.
In the heart of Mercari, there’s a golden rule when it comes to our services: Every failed HTTP request must get a second chance, with retries using exponential backoff plus jitter. But alas! Our new friend Ky didn’t come with a built-in jitter for its retry delays.
Just like a perfectly sized gift wrap that falls short by an inch, Ky seemed to be missing that final tug to make it the perfect fit for us.
But, as you may have guessed, at Mercari, we’re all about coding, coffee, and most importantly – turning curves into solutions! So, I dusted off my keyboard and opened a PR to boost Ky with a custom delay function.
And voila! Just like that, I added a shot of jitter to Ky, making it a perfect blend for our needs – just like adding a splash of marshmallow to hot cocoa! So now, not just us, but the entire Ky family can enjoy jitter-backed retry delays with our spruced up version. A true testament to the holiday spirit of gifting that resonates in the open-source community!
Powering Up pkgx – Strengthening ‘engines’ for npm Versioning: pkgx
Contribution: https://github.com/pkgxdev/pkgx/pull/807
Ever got a long-awaited gift and discovered it needed a little tweaking before it was perfect? That was the case when we got our hands on the new tool, pkgx. This promising promise-saver was supposed to smooth out the hassle of constantly updating the node and npm versions as we moved between repositories. It felt like it was about to be a lifesaver… or so we thought.
We noticed that pkgx, although impressive, wasn’t quite hitting the spot when it came to reliably fetching the right versions from the package.json file. It was as if our brand new automated toy train was missing a tiny gear, preventing it from gliding flawlessly on the tracks; pkgx didn’t quite mesh well with our company’s use of "engines" to define the node/npm version.
But in the spirit of problem-solving (and perfect gift-making), we rolled up our sleeves and got down to nitty-gritty. We took our little automated toy train (pkgx), fixed the missing gear, and soon enough it was speeding down the coding rails like a charm. By revamping pkgx to jive with our systems, it became a much more effective helper in its quest to detect and install the correct npm version for each node upgrade.
Now, the rejigged pkgx chugs along doing its task for not just us, but every coder in the pkgx community. Our small tweak – much like a tiny gear in a toy train – has helped fuel smoother rides through the terrain of coding and open source. After all, every improvement, no matter how tiny, counts!
Sprucing Up SQLFluff – Fixing Parameter Name Problems: sqlfluff
Contribution: https://github.com/sqlfluff/sqlfluff/releases/tag/2.3.2
Let’s dive into another one of our tech journeys, this time featuring a detour with sqlfluff. At Mercari, we have a cozy relationship with sqlfluff, especially when we want to nudge our SQL code for a quick sanity check. But like that one pesky bulb in a string of fairy lights, we noticed a feature that wasn’t shining as bright – handling parameters in SQL.
Now, in a perfect world, we would simply mention all parameter names in the sqlfluff config. Easy, right? Well, imagine having to dart around, updating multiple fields every time you introduce a new parameter. A bit like having to re-decorate your entire Christmas tree because you added a new ornament! Definitely an unwelcome chore.
So, feeling a tad more Grinch-like, we set out to solve the issue. Our goal: to make sqlfluff work smarter, not harder, by bypassing the need to manually add each parameter name.
And guess what? We weren’t the only ones who stumbled upon this issue – multiple others in the community encountered the same pothole. But hey, challenges are just opportunities in disguise! After observing the behavior across different environments and solving a delightful array of mini-mysteries, we managed to crack the code.
Our solution was like a nifty new ornament hook, making it easier for everyone to hang new baubles (or parameters, in our case)! Now, sqlfluff users can jingle all the way to smoother coding, thanks to this neat trick up our sleeves. It’s a small yet impactful gift to the sqlfluff community, and a sweet reminder that the spirit of giving can turn problems into presents!
Wrapping Up: Reflecting on a Year of Open Source Generosity
And there we have it, folks! We’ve reached the end of the trail on our open source journey for the year. What a ride it’s been! From glitches to shiny patches, our adventure helped us realize countless ways how even the littlest contributions can make a big wave in the enormous pond of open source.
Nothing screams holiday spirit more than being part of this techy potluck, each dev bringing their unique dish – a line of code, a bug fix, or an idea – we’re all in it together, adding our own spark of flavor. But just as that last chocolate in the advent calendar doesn’t mark the end of treats, our journey in contributing to open source definitely doesn’t stop here. Next year, we’ll take off on yet another journey, ready to face new challenges, ready to bring more to the potluck.
So, here’s to everyone who was part of this awe-inspiring potluck of open source. To each and every giver, to each and every solution, regardless of size. To you.
As we’re wrapping up another year, let’s remember to keep the spirit of sharing, connecting, and helping with us not just during the holiday season but throughout the year. After all, if there’s one thing our open source journey has reinforced, it’s that together, we can create significant change. Happy Holidays!
