Untangle your dependencies.
NoodleOps reads a pnpm repository on your Mac, shows where every package came from and why it is in the lockfile, and tries an upgrade in fresh clones against your own checks — without ever writing to your repository.
macOS · pnpm v9 lockfiles · your repository is never written
is-number in the lockfile?2 paths- apps/web
fill-range 7.1.1to-regex-range 5.0.1is-number 7.0.0
- packages/cli
micromatch 4.0.8braces 3.0.3fill-range 7.1.1to-regex-range 5.0.1is-number 7.0.0
Read from the lockfile's record, not from what happens to be on disk.
is-number 6.0.0 → 7.0.0Ready for reviewThe phrases are about your configured checks and nothing more: there is no overall pass or fail.
The problem
An update tells you what is new. It rarely tells you what you have.
Packages you never chose
Most of a lockfile arrives through something else. Finding which of your workspaces pulled a package in, and through what, means reading the lockfile by hand.
The manifest and the lockfile disagree
A range edited in package.json and never installed, or a record left behind, looks fine until the next install decides for you.
An upgrade you learn about too late
Whether an upgrade holds is usually found out in CI, after it is merged, with nothing to compare against.
How it works
From a folder on your Mac to one upgrade you can review.
Everything happens locally. The app reaches two places: the public npm registry, for package metadata and the packages an upgrade installs, and your NoodleOps account, to sign in and confirm your subscription — never with your code, paths or reports.
- 01
Add a local repository
Choose a folder on your Mac. NoodleOps reads its manifests and pnpm lockfile, and never writes to it.
read-only - 02
Read what is there
Every declared dependency beside what the lockfile recorded, the drift between them, and the dependency tree.
workspaceswhy paths - 03
Choose one upgrade
One package, one candidate version, and the checks that decide it — confirmed before anything runs.
confirmed - 04
Verify in fresh clones
The baseline and the candidate are each installed into a clean clone of your committed code and run your checks. You review the evidence.
sandboxedyour checks
Why is it here
Know why, not just what.
Pick any package in the tree and see the paths that bring it in — up to 20, from each workspace that depends on it — including optional edges, marked as such.
- Every declared dependency beside what the lockfile recorded, in every workspace
- Drift stated plainly: a changed range, a declaration never installed, a record left behind
- Credentials in a registry URL are redacted before anything is shown
is-number in the lockfile?2 paths- apps/web
fill-range 7.1.1to-regex-range 5.0.1is-number 7.0.0
- packages/cli
micromatch 4.0.8braces 3.0.3fill-range 7.1.1to-regex-range 5.0.1is-number 7.0.0
Read from the lockfile's record, not from what happens to be on disk.
| Package | Declared in | Declared | Recorded | Drift |
|---|---|---|---|---|
| react | apps/web | ^19.0.0 | 19.3.0 | Matches the lockfile |
| typescript | packages/core | ~7.0.0 | 7.0.2 | Matches the lockfile |
| vite | apps/web | ^8.2.0 | 8.3.0 | Specifier drift |
| left-pad | packages/cli | 1.3.0 | — | Declared only |
is-number 6.0.0 → 7.0.0Ready for reviewThe phrases are about your configured checks and nothing more: there is no overall pass or fail.
Upgrades you can read
One upgrade, checked on both sides.
NoodleOps installs your committed code twice — as it is, and with the candidate — each in its own clone and its own store, with install scripts off. Then it runs the checks you chose, in order, and shows you each side's result and its evidence.
- A required check that fails on the baseline stops the run before any candidate exists, unless you decide to continue
- A stop is final: a run you stop never advances
- Logs are shown as inert, bounded text, and every report is re-verified before it is shown
Your repository
Read, never written.
NoodleOps works on copies. The folder you add is only ever read.
Local by design
Repository data stays on your Mac. The account service stores your account, team and billing — and no repository data.
Sandboxed runs
Each install and check runs in a macOS sandbox that may write only inside its own clone and store.
Two network destinations
The app reads package metadata, and downloads the packages an upgrade installs, from the public npm registry; and it signs in to your NoodleOps account and renews its subscription lease there, sending no repository data. It reaches nothing else.
Honest scope
Built for projects you trust. The sandbox is real, but the first version does not claim to contain a hostile repository.
Pricing
For one developer, or a team.
Personal
One seat, billed monthly.
Team
Per seat, billed monthly, with an owner, admins and members.
Questions
What developers ask first.
- Which package managers does it read?
- pnpm, with v9 lockfiles, including workspaces. Other package managers are not supported.
- Which platforms?
- macOS. The app runs every upgrade on your own machine.
- Does it change my repository?
- No. Upgrades run in clones under the app's own storage; your folder is never a place anything is written to.
- What does a passing upgrade prove?
- That the checks you configured passed on both sides, and how the two compare — no more. NoodleOps gives no overall verdict.
- Which projects can it run upgrades for?
- Projects you trust. Runs are sandboxed, but the first version does not claim to contain a hostile repository.
- Where does my code go?
- Nowhere. Repository data stays on your Mac; the account service holds your account, team and billing, and no repository data.
Your dependency graph, finally legible.
See what is in a repository, and why — then try the upgrade before you merge it.
Create an account