# Grayhat Blog Tag: Vercel

> Expanded public blog context for posts tagged Vercel.

## Page

- [Vercel Tag](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/tag/vercel)
- [Vercel Tag LLM Context](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/tag/vercel/llms.txt)
- [Root LLM Context](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/llms.txt)
- [Root Full LLM Context](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/llms-full.txt)
- [Tag API](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/api/public/v1/tags/vercel)

## Tag Details

- Slug: `vercel`
- Description: Not provided
- Post count in current snapshot: 2

## Current Posts

- [Fixing a Next.js Documentation Issue](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/fixing-a-next-js-documentation-issue) - How a small bug in the MSW example led me to contribute my first merged PR to Next.js, and what it taught me about open source.
- [Secure your ship](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/secure-your-ship) - In the fast-paced world of modern web development, where tools like Vercel, Checkly, Mixpanel, and Hotjar have revolutionized workflows, it's easy to focus on the efficiency gains these platforms bring while inadvertently neglecting a critical aspect—security. As development teams expand and diversify their skill sets, the boundaries of projects expand exponentially. With more contributors, integrations, and code to manage, the attack surface grows significantly, amplifying the potential risks.


## Child Route Content

### [Fixing a Next.js Documentation Issue](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/fixing-a-next-js-documentation-issue)

- Slug: `fixing-a-next-js-documentation-issue`
- Published: 2025-10-24T18:22:25.000+05:00
- Updated: 2025-10-24T18:31:40.000+05:00
- Reading time: 4 min
- Tags: Open Source, Vercel, Next.js, JavaScript, Open Source Community
- Authors: Hamad Ullah
- Visibility: public

A few months ago, I was assigned a ticket to integrate **Mock Service Worker **in to Ruby for API mocking. While trying to make things work, I stumbled upon a confusing issue, not in my code, but in the **Next.js documentation itself**. What began as a simple debugging session turned into a pull request that’s now officially merged into the Next.js repository.

This is a blog post on of how I found an issue, what I did to fix it, and why contributing to open source is essential.

### How I Found the Issue

I setting up **API mocking** using **MSW** in our Next.js application. For local development, MSW is incredibly useful, it intercepts network requests and allows us to simulate API behaviour without touching the backend.

I followed the Next.js documentation example for MSW setup carefully, but something just wasn’t working. The **worker setup** wasn’t behaving as described, in fact the imports were unrecognized.

After digging into the issue for a bit, I realized the example itself had a **outdated setup,** something subtle that could easily trip up any developer trying to follow it step by step.

I checked GitHub, and someone had already opened an issue describing the same problem. I realized the documentation is outdated and added a to-do for future reference to fix it in my free time.

### What I Did

I cloned the Next.js repo, navigated to the documentation example, and made the necessary fix. The goal was simple, make the MSW example actually work as advertised.

After verifying the fix locally and ensuring that it didn’t break anything else, I submitted a **pull request** with a short, clear explanation of what the problem was and how my change resolved it.

The **Pull Request **I made is the following**:**

Fix/msw-issue-68521 by HamadUllah16 · Pull Request #83482 · vercel/next.jsFix: 68521 Updating outdated with-msw example
The with-msw is outdated and doesn't work with the latest msw version.
What?
The with-msw example is outdated and does not work with the latest msw…*GitHubvercel*Soon after, one of the maintainers reviewed it, validated the change, and merged it.

That was a really satisfying moment, not just because my code was now part of Next.js, but because other developers wouldn’t need to waste their time figuring out why the setup isn't working as expected.

### Why I Think It Got Merged

Open source maintainers get hundreds of PRs. What I did was review the ones that actually got merged. I think that’s what worked in my case:

- I explained *why* the fix was needed, not just *what* it did.
- I referenced the existing issue and made it easy to verify the bug and the fix.
- The PR didn’t introduce extra complexity. It was a focused, single-purpose fix.
- I followed the repo’s contribution guide and conventions closely.
- I added a demo video which made it easier for reviewers to glance over my changes. Even though they'd still test locally, it establishes trust.

I tried to make it as contextual and easy to review as possible, because open-source reviewers are often doing this work in their free time - it's best to utilize their time in the best possible way, in the rare hours they get it.

### Why is open source development important?

Open source is the invisible backbone of modern web development. Majority of the frameworks, libraries, and tools we use, from **React** to **Next.js**, **MSW**, **Tailwind**, and beyond, are built on the collective effort of thousands of developers who share their work openly.

Contributing back isn’t just a nice gesture, it’s how the web keeps evolving. When you fix a bug, improve documentation, or clarify an example, you’re helping thousands of other developers avoid the same confusion.

What makes open source especially powerful in the **JavaScript ecosystem** is how interconnected everything is. A small fix in one project can ripple across others, improving developer experience far beyond a single codebase.
In a world where frameworks constantly transform and build on each other, collaboration is what keeps innovation moving forward.

Ruby – AI Powered Pitch Platform for Smarter SalesClose deals faster with Ruby. Instantly generate personalized, insight-driven sales pitches for any company using AI. Trusted by modern sales teams to win more.**Check out Ruby, the project I'm working on at Grayhat.

I'm open to learn more in the future about Next.js and contributing to open-source. Stay tuned!

### [Secure your ship](https://grayhat-company-blog.grayhatstudio.workers.dev/blog/secure-your-ship)

- Slug: `secure-your-ship`
- Published: 2023-10-25T15:36:00.000+05:00
- Updated: 2024-05-10T13:49:03.000+05:00
- Reading time: 3 min
- Tags: Supply Chain Security, NPM, Open Source, Open Source Community, JavaScript, Typescript, Vercel, Innovation, Tech
- Authors: Asfand Yar
- Visibility: public

*In the fast-paced world of modern web development, where tools like Vercel, Checkly, Mixpanel, and Hotjar have revolutionized workflows, it's easy to focus on the efficiency gains these platforms bring while inadvertently neglecting a critical aspect—security. As development teams expand and diversify their skill sets, the boundaries of projects expand exponentially. With more contributors, integrations, and code to manage, the attack surface grows significantly, amplifying the potential risks.

Real-world incidents serve as stark reminders of the impact of security vulnerabilities. The Equifax breach in 2017 exposed sensitive data from 147 million individuals due to unpatched software, and the Colonial Pipeline ransomware attack in 2021 disrupted critical fuel supplies. Security lapses have even derailed major mergers and acquisitions, as seen in the delayed acquisition of Yahoo by Verizon following data breach revelations. The SolarWinds exploit underscored the risks associated with unlicensed software, affecting numerous networks.

### AI & Blockchain bring more security concerns than before.

Supply chain challenges wield a profound impact on the growth trajectory of today's AI and blockchain startups. In the AI realm, dependencies on open-source libraries and frameworks make startups vulnerable to security breaches and compromised model outputs, disrupting development timelines and compromising data integrity. Likewise, in the blockchain space, vulnerabilities in smart contract frameworks and consensus mechanisms due to supply chain issues can undermine the trustworthiness of distributed ledgers, leading to compliance issues and investor concerns.

These vulnerabilities often arise from various sources such as unpatched software, misconfigurations, and human error. The complexity introduced by open-source components and third-party integrations necessitates thorough vetting and monitoring to counter potential threats.

### Enter SecOps.

Integrating Supply Chain Security and Security Operations (SecOps) into development cycles becomes imperative for proactively addressing vulnerabilities. However, current security solutions often suffer from alert fatigue, overwhelming users and diluting the impact of critical notifications.

Enter listen.dev, a new player in the dynamic landscape of web development challenges, offering a fresh perspective on fortifying security measures seamlessly.

### Make Security Actionable.

If you've used dependabot before, you'll immediately know what the term "alert fatigue" means even if you've never read about it before. Basically, when you receive a flood of notifications and alerts but don't have an action item for them, and they keep piling up, you eventually start ignoring the notifications.

That's deadly for security; you start ignoring once, and it goes permanently under the rug **until it's too late.**

We've had some insider conversations with listen.dev, and according to their claims, security is no longer an afterthought. It's gotta be part of the SDLC (Software Development Life Cycle).

What does that mean for devs? Just like how Vercel plugs themselves right into the everyday DX (Developer Experience) of a developer with their GitHub integration, listen.dev also has a GitHub integration which gives you 1) Actionable insights, 2) A "Security Review" mechanism (Yes, it works exactly as it sounds like. It's a security approval for each PR which has security vulnerabilities).

On the side, Listen features the standard:

**Real-time Security Scans:** By embedding real-time security scans into each pull request, listen.dev facilitates early identification and resolution of vulnerabilities during code integration.

**DNS Profiling:** A standout feature, listen.dev's DNS profiling provides proactive alerts for potential malicious attacks, acting as a shield against looming threats.

**User-Friendly Interface:** listen.dev distinguishes itself by offering a user-friendly interface focusing highly on its DX (taking inspiration from Vercel), making security measures not only effective but also accessible.

**High Customization:** The platform's high level of customization caters to diverse user needs, ensuring improved security and ease of use with tailor-made solutions adaptable to specific requirements.

In the ever-evolving digital landscape, listen.dev emerges as a promising contender, offering robust security enhancements alongside a user-centric approach. Its suite of features designed for practical usability and adaptability signals a potential shift towards more secure and personalized web development practices.

The key is not just about adopting new tools but integrating security seamlessly into the development workflow. It's necessary now more than ever before to be proactive than reactive - a supply chain vulnerability or hack could mean life or death for a company in today's privacy-savvy world.

At Grayhat, we bring impossible to life, and challenge tech to its very extreme. A team of ragtag hackers, with a thirst for innovation, we don't shy from taking on early-stage design and development challenges which define the gray line which sits between the possible and impossible.

Interested in working with us? Drop us an email at sales@grayhat.com.pk

Author: Asfand Yar Aftab