inrepo

inrepo vendors upstream git repositories directly into your project.

Use it when you want the ergonomics of local source code, but still want the discipline of pinned dependencies. Instead of hiding changes in node_modules, publishing a private package, or maintaining a long-lived fork, inrepo gives you a repeatable recipe:

upstream git commit + your committed patches = generated local package

You edit the generated copy in inrepo_modules/, capture your changes into inrepo_patches/, and let teammates or CI rebuild the same tree with inrepo sync.

Install

npx inrepo --help

Or globally via Homebrew:

brew tap inthhq/tap
brew install inrepo

Both install the same npm-published artifact. inrepo requires Node.js 20+.

Why this exists

Package registries are convenient, but they are also an attack surface. Compromised package publishes, suspicious dependency changes, and install-time scripts are becoming more common.

inrepo is not a magic security boundary, and it does not replace lockfiles, audits, or incident response. It gives you a clearer operating model for packages you care about deeply:

• inrepo.lock.json pins the exact upstream commit for each module.
• inrepo_patches/<name>/ stores your team's committed overlay files and deletions.
• inrepo_modules/<name>/ is generated output rebuilt from the lockfile plus overlay.

That makes upstream code easier to inspect, patch, and reproduce when the package manager ecosystem gets noisy.

What to commit

Commit:

• inrepo.json or package.json#inrepo
• inrepo.lock.json
• inrepo_patches/

Do not commit:

• inrepo_modules/
• .inrepo/

Use inrepo verify in CI to catch a checkout that no longer matches the lockfile and overlay.