When a Standalone Repo Is Overkill — Migrating a 7KB Widget Into a Monorepo Package

I've been there. You build a tiny, beautiful widget. It works perfectly. You're proud of it. So you give it its own GitHub repository. You write a README. You set up CI. You tag a version. You feel like a proper open-source maintainer.

Then you realize: it's 7KB. One source file. Zero runtime dependencies. And nobody else on the planet will ever use it except your own projects.

I did exactly this with a feedback widget I built for Shinkofa. And last week, I killed the standalone repo, moved the 7KB into Shinkofa-Shared/packages/feedback-widget, and felt an immediate sense of relief.

Here's the decision framework I wish I'd had before creating that repo in the first place.

The Real Cost of a Standalone Repo

We romanticize small, focused repositories. They feel clean. They feel modular. They feel like we're doing architecture right.

But let's be honest about what a standalone repo actually costs:

• Cognitive overhead: Every repo is a context switch. Where is that thing? Oh right, the other repo.
• Duplicated tooling: ESLint config, TypeScript config, package.json scripts, CI pipeline — all copied or maintained separately.
• Dependency hell: Version mismatches across repos. You update the widget, forget to bump in the main app, and suddenly things break silently.
• Discovery friction: Nobody browses your 47 repos. They search one codebase. If it's not there, they rebuild it.

The widget was 7KB. Its package.json was bigger than the actual source code.

The 3 Questions I Now Ask Before Creating a Repo

After this experience, I wrote down three criteria. If you answer "no" to any of them, don't create a standalone repo. Put it in the monorepo.

1. Does it have independent lifecycle?

A standalone repo makes sense when the component evolves on its own schedule — different release cadence, different maintainers, different consumers who don't share your monorepo.

My feedback widget? It changed when the main app changed. Always. Zero external consumers. No independent lifecycle.

Decision: Monorepo.

2. Does it need its own CI/CD?

If your component has complex build steps, cross-platform testing, or deployment to a registry, a separate repo might justify itself.

My widget: one TypeScript file, compiled in 0.3 seconds as part of the main build. No tests beyond what the main app already ran. No deployment — it was bundled into the app.

Decision: Monorepo.

3. Would you be embarrassed if someone saw it?

This is the honesty check. If you're creating a standalone repo because it "looks professional" but the code is trivial, you're optimizing for appearance, not engineering.

My widget was clean but trivial. 7KB. One file. Zero dependencies. Giving it its own repo was architectural cosplay.

Decision: Monorepo.

The Migration (It Took 11 Minutes)

Here's what the actual migration looked like for Shinkofa-Shared/packages/feedback-widget:

# Before: standalone repo
~/repos/shinkofa-feedback-widget/
  ├── src/
  │   └── index.ts          # 7KB
  ├── package.json           # 1KB (bigger than the code)
  ├── tsconfig.json          # copied from main project
  ├── .eslintrc.js           # copied from main project
  ├── .github/
  │   └── workflows/
  │       └── ci.yml         # 40 lines, 90% boilerplate
  └── README.md              # 2KB (nobody read it)

# After: monorepo package
~/repos/shinkofa-shared/
  └── packages/
      └── feedback-widget/
          ├── src/
          │   └── index.ts   # 7KB (unchanged)
          └── package.json   # 5 lines, just name + version

I deleted 4 files, moved 1 file, and removed an entire CI pipeline. The widget still works exactly the same. But now:

• It's discoverable in the same codebase as everything else
• It uses the same TypeScript config, ESLint rules, and build pipeline
• I can change it and the main app simultaneously in one commit
• No version management — it's always in sync

When Standalone Repos Do Make Sense

I'm not anti-standalone-repo. I've worked at Meta with their massive monorepo and at AWS with thousands of polyrepos. Both have their place.

A standalone repo makes sense when:

• External consumers: People outside your team/organization depend on it
• Different release cadence: It ships independently from the main app
• Specialized CI: It needs platform-specific testing (mobile, embedded, etc.)
• Team boundaries: Different teams own it with different workflows

But for a 7KB widget that only your app uses? No. Just no.

The Insight Nobody Talks About

Here's what I learned that surprised me:

The desire to create standalone repos is often a symptom of not trusting your monorepo tooling.

I created that separate repo because I was afraid of coupling. I thought putting everything in one place would make the codebase messy. But the opposite happened — the monorepo forced me to be disciplined about boundaries without the overhead of separate repos.

The widget didn't need independence. It needed a home.

A monorepo with clear package boundaries gives you the best of both worlds: modularity without fragmentation. You get the isolation of separate packages with the discoverability and consistency of a single codebase.

The Ermite Shinkofa

The Ermite Shinkofa