From “I Have No Idea” to “It Works!”
This was literally my first ever Hacktoberfest contribution, so I was trying to find the repos that are not too crazy but still useful. The Flowglad project looked cool, but for me it’s big. Tons of folders, files, and a backend setup. But the issue I worked on is seems not that hard, Its pretty straight forward decribed the issue and the maintainer wrote a really detailed description. They listed the exact files I’d need to change and what kind of fix they wanted: basically, replace a piece of hardcoded metadata with something dynamic using a function called generateMetadata() from Next. So I thought okay, even if I don’t fully understand the project, at least I know where to start and what should I do.
Before touching the code, I tried to follow the contribution guide to setup. The project runs inside Docker, and honestly, I’m not that comfortable with Docker yet. I’ve used it before, but only lightly. At first, I wasn’t even sure how to run it in a right way, because there were a bunch of services and containers to spin up. Luckily, after a few tries, I managed to get it running.I didn’t fully set up authentication or connect a live database, but it was enough to work on the code and do some testing.
The issue mentioned using Next.js’s generateMetadata()
function.
That was new to me — I had to read through Next.js docs to understand how it works. Basically, it’s a server-side function that can fetch data and return a metadata object. After some digging, I found that product and organization info was retrieved using two key helpers: adminTransaction()
, selectPriceProductAndOrganizationByPriceWhere()
. These functions already returned the info I needed — I just had to use them correctly. Once I understood the data flow, the actual code changes were straightforward. I added a new generateMetadata()
function to two files:
• /platform/flowglad-next/src/app/price/[priceId]/purchase/page.tsx
• /platform/flowglad-next/src/app/product/[productId]/purchase/page.tsx
Inside each, I fetched the related product and organization names, then returned them in the page’s metadata as maintainer required.
return {
title: `${organization.name} | ${product.name}`,
};
After pushing the PR, the maintainer replied super nicely.
They said the fix looked perfect, but asked me to add a unit test to cover both the dynamic title and the fallback case. When the maintainer commented, “Looks great — can you add some unit tests?”, I thought, “Sure, that won’t be too bad.”, since before I pushed I have tested the logic to make sure the code is correctly. But, it took me way longer than the actual fix. This project doesn’t just run pnpm test locally. All the tests are executed inside Docker containers, and the data they use comes from a real test database instance, not mocked data. So instead of faking responses, the tests actually query data from the Dockerized environment. At first, I tried writing a mock test — but I could't get it passed.
So I went back and started studying how other contributors wrote their tests. I read a few previous PRs where people added tests.
So that helped me understand two key things:
1. Tests should run using the real DB data from the Docker instance.
2. There are helper utilities listed in the CONTRIBUTING.md
file that make it easier to query data and clean up test environments.
Once I realized that, things started clicking. I used those helper functions instead of trying to build my own mocks. It took some trial and error to understand how to properly import and call them, but I eventually got it working. Watching all green checks pop up in the logs was very satisfying.
After all done, my first PR get merged. It gave me confidence that I can step into a real-world project, read the docs, experiment, and figure it out.
Top comments (0)