Do You Really Need That Module?

Every time a new major version of Nuxt drops, I notice a pattern: GitHub issues, Reddit threads, Discord messages, all variations of "Module X doesn't work" or "I can't upgrade because of package Y". And this isn't unique to Nuxt.

The Upgrade Dance

In the Laravel world, the story is the same. A new version drops, and you'd see people unable to upgrade because a package they rely on hasn't caught up yet. I've seen this across Nuxt, Laravel, Rails... the framework changes, the pattern doesn't.

In the Nuxt world, I've watched Daniel Roe personally open dozens of PRs across community modules to ensure compatibility with new releases. That's incredible dedication, but it also highlights the problem: when one person has to go around fixing other people's packages for an upgrade to go smoothly, something's off.

Now, to be fair, this is a completely valid complaint. Most module authors are volunteers. They have day jobs, families, lives. They built something useful, shared it with the community, and moved on. They're not on standby waiting for the next major release so they can spend their weekend updating their package. And that's okay. We should be grateful, not entitled.

Nuxt actually does something smart here with its compatibility flags. You can opt into upcoming breaking changes early, test your app against the next major version, and report issues before it actually ships. More frameworks should do this.

But none of that changes the core issue.

The Real Problem

After years of working across different stacks as a developer and consultant, I've come to a conclusion that might be unpopular: most of us rely too heavily on third-party packages.

I've seen projects where a module is installed for something that could be done in 20 lines of code. Twenty. Lines. And now that project is locked into someone else's release schedule, someone else's breaking changes, and someone else's security practices.

Sometimes I think we're just... lazy? Or maybe it's more that we've been conditioned to reach for npm install before we reach for our keyboard. Either way, we end up in situations where we can't update our projects because module X, Y, and Z haven't caught up yet.

And we haven't even talked about security. Third-party dependencies are one of the most common attack vectors. Apps and websites get compromised through vulnerabilities in packages that the developers didn't even know were in their dependency tree. Every package you add is a door you're leaving open for someone else to manage.

What I Think We Should Do

Before adding a module or package, ask yourself honestly: do I actually need this?

In most cases, the answer is no.

Here's how I approach it:

• If it's less than ~50 lines of code to implement yourself, just write it. You'll understand it better, you'll control it entirely, and you won't be waiting on anyone to update it.
• Keep your dependency count low. Fewer dependencies means fewer things that can break on upgrades, fewer security risks, and a smaller bundle.
• When you do need a package, prefer ones with official support. For Nuxt, check the official modules first. They're maintained by the core team and are guaranteed to be compatible on day one.
• Look for trusted maintainers. Someone like Harlan Wilton, a Nuxt core team member, maintains several modules (SEO, OG Image, etc.) and consistently keeps them up to date with new releases. That matters.

Does this mean community contributors are wasting their time? Absolutely not. The ecosystem thrives because of them. But as consumers, we should be intentional about what we bring into our projects.

The Upside of Writing It Yourself

There's a bonus here that people overlook: you actually learn how the framework works.

Nuxt gives us modules, plugins, composables, server utilities, and great documentation on how to build all of them with minimal overhead. When you write that 20-line composable instead of installing a package, you're not just reducing dependencies, you're building a deeper understanding of the tool you use every day.

That understanding compounds. The next time something breaks, you're not lost staring at a module's source code wondering what it does. You already know, because you've written similar things yourself.

That's It

TLDR: use as few packages as possible. Nuxt gives you the tools and the docs to build most of what you need internally. Take advantage of that.

Next time you're about to install a package, take a moment. Read the source. Check how many lines of code it actually is. See when it was last updated. Look at how many dependencies it pulls in.

You might surprise yourself with how often the answer is: "I can just write this myself."