HumanOnlyWeb

🍁 writer of code. drinker of coffee. human on the web.

Do You Really Need That Module?

By HumanOnlyWeb

Every time a new major version of Nuxt drops, the same thing happens. GitHub issues, Reddit threads, Discord messages — "Module X doesn't work", "I can't upgrade because of package Y". Same thing in Laravel, same thing in Rails. The framework changes, the pattern doesn't.

Upgrades

I've watched Daniel Roe personally open dozens of PRs across community modules to make sure they work with new Nuxt releases. That's awesome, but also kind of wild — one person going around fixing other people's packages so an upgrade can go smoothly.

Module authors are volunteers. They have jobs and lives. They shared something useful and moved on. Nobody's sitting around waiting for the next major release so they can spend their weekend updating a package. That's fair.

Nuxt does help here with compatibility flags — you can opt into breaking changes early, test against the next major, and report issues before it ships. More frameworks should do this.

But the real issue is somewhere else.

Too Many Packages

I think most of us (myself included) reach for npm install way too quickly. I've seen projects where a module is installed for something you could write in 20 lines. And now that project depends on someone else's release schedule, someone else's breaking changes, someone else's security practices.

Then there's the security side. Third-party deps are one of the most common attack vectors. Apps get compromised through packages the developers didn't even know were in their dependency tree. Every npm install is another thing you're trusting someone else to keep safe.

What I Do Instead

Before adding any dependency, I ask: do I actually need this? Most of the time, no.

  • If it's less than ~50 lines to write myself, I just write it. I'll understand it better and I'm not waiting on anyone to update it.
  • When I do need a package, I check the official Nuxt modules first. Core team maintains them, guaranteed compatible on day one.
  • I look at who maintains it. Someone like Harlan Wilton (Nuxt core team) maintains several modules (SEO, OG Image, etc.) and keeps them up to date. That matters.

This isn't a dig at community contributors — the ecosystem wouldn't exist without them. But I try to be deliberate about what I bring into my projects.

You Learn More This Way

This is the part people skip over. When you write that composable instead of installing a package, you actually learn how the framework works.

Nuxt gives you modules, plugins, composables, server utilities, and solid docs on how to build all of them. Next time something breaks, you're not staring at a module's source code trying to figure out what it does. You already know, because you've written similar stuff yourself.

That's It

TLDR: use as few packages as possible. Nuxt gives you the tools to build most of what you need yourself.

Next time you're about to install something, read the source first. Check how many lines it actually is. Look at how many dependencies it pulls in. You'd be surprised how often you can just write it yourself.

All Comments 0

Be the first to comment.