What it checks
Paste a package.json and every dependency gets the same treatment: how far behind it is, what changed on the way, and what an update would cost you.
How far behind
Each dependency is classed as a major, minor or patch update, with 0.x versions read the way semver means them. The timeline marks every release between your version and latest, and every breaking boundary on the way.
Every release note in between
Notes come from GitHub Releases, with CHANGELOG.md as a fallback for the gaps. They start collapsed, can be filtered by major, minor, patch or breaking, and breaking changes are highlighted in the text.
Known vulnerabilities
Advisories from OSV.dev are matched against the exact version you use, so you only see the ones that apply, each with the release that fixes it.
Will latest still fit
Before you update, the Node requirement of latest is checked against your engines field, and its peer dependencies against the versions your project already uses.
Packages nobody maintains
A repository archived on GitHub, or two years without a release, is flagged so you can plan a replacement before it turns into a problem.
The command to run
Every outdated package comes with its install command for npm, pnpm, yarn or bun, keeping your ^, ~ or exact pins. Major updates also offer the newest version without breaking changes, and the whole list can be updated in one go.
All your repos in one place
Sign in with GitHub to see your public repositories on one dashboard. Track the ones you care about, pick each package.json in a repo with a client and a server, and check them all with one click.
Your real versions
Add package-lock.json, yarn.lock or pnpm-lock.yaml and the check starts from what is actually installed instead of the lowest version a range allows. The lockfile also picks the package manager for the commands.