Skip to content
Product

Introducing Ovvoc: Dependency Updates That Actually Fix Breaking Changes

Ovvoc team··4 min read

Dependency updates are one of those problems every team knows about and nobody wants to deal with. Tools like Dependabot and Renovate help by bumping version numbers and opening PRs. But when an update introduces a breaking change — a renamed API, a removed method, a new routing syntax — those tools leave you on your own.

That's the gap Ovvoc fills. Today we're launching the first dependency update tool that doesn't just bump versions — it fixes breaking changes.

The problem: dependency updates are broken

Most teams have a backlog of outdated packages they keep promising to update "next sprint." The easy updates get done. The hard ones — the ones that require code changes — pile up. Over time, the gap between your dependencies and their latest versions widens. Security vulnerabilities accumulate. Migration paths grow longer and more painful.

Existing tools solve the easy 70%. They bump a version in package.json, regenerate the lockfile, and open a PR. But when Express 4 becomes Express 5, when React Router 5 becomes React Router 6, when ESLint 8 becomes ESLint 9 — you're still doing the hard work by hand.

What Ovvoc does differently

Ovvoc handles all 25 categories of npm dependency updates, organized into three tiers:

  • Categories 1–6: No code change needed. Version bumps, lockfile regeneration, type updates, security patches, devDependencies.
  • Categories 7–13: Simple code transforms. Renames, import path changes, parameter adjustments, config migrations, deprecated method replacements.
  • Categories 14–25: Complex transforms. Paradigm shifts, architecture changes, hidden behavior changes, coordinated multi-package updates.

For categories 7 and above, Ovvoc uses deterministic AST transforms powered by the OXC parser to rewrite your code at the syntax tree level. No fragile regex. No string replacement. Real structural code modification.

The pipeline: Clone → Update → Build → Test → PR

Every update follows the same pipeline:

  1. Clone your repository into an ephemeral container
  2. Update the dependency and apply any necessary code transforms
  3. Build the project to verify compilation
  4. Test the project to verify behavior
  5. PR (only if all tests pass) with confidence score and detailed description

If tests fail, you don't get a broken PR. You get a detailed failure report explaining what was attempted, what broke, and why. Your main branch is never affected.

Available today: npm/Node.js

Our MVP focuses on the npm ecosystem. This covers all npm packages, package.json configuration, and Node.js tooling. We've tested against 100 real-world repositories with a 95%+ success rate on version-only updates and verified AST transforms for Express 4→5, React ecosystem updates, and dozens of other common migration paths.

What's next

We're starting with npm because it's the largest package ecosystem and where dependency debt accumulates fastest. But the architecture is designed to be ecosystem-agnostic. Python, Go, and Rust support are on the roadmap.

The dependency problem by the numbers

The scale of the dependency problem is staggering. According to the Synopsys Open Source Security and Risk Analysis (OSSRA) 2024 report, 84% of codebases contain at least one known vulnerability originating from outdated dependencies. These aren't theoretical risks — they're documented, exploitable weaknesses sitting in production code.

The average npm project pulls in over 300 transitive dependencies. That's 300 packages you didn't choose, maintained by people you've never met, each with their own release cadences and breaking change policies. When any one of them publishes a security patch, you need to know about it. When any one of them changes an API, you need to adapt.

Industry surveys consistently show that engineering teams spend 10–20% of their time on maintenance work, with dependency updates being a significant chunk of that. For a 10-person team, that's 1–2 full-time engineers worth of effort going to keeping things current instead of building new features.

Our approach: deterministic + AI hybrid

Ovvoc takes a pragmatic approach to code transformation. For categories 7–13 — which cover renames, import path changes, parameter adjustments, config migrations, and deprecated method replacements — we use deterministic AST transforms. These transforms are reproducible, predictable, and fast. Given the same input, they always produce the same output. There's no randomness, no "temperature" setting, no chance of hallucination.

For categories 14–25, the patterns are too complex or too context-dependent for static rules. A paradigm shift from class components to hooks, an architecture change from callbacks to async/await, a hidden behavior change in how a library handles edge cases — these require understanding intent, not just structure. That's where AI comes in.

But our AI usage is narrowly scoped. We don't hand the AI your entire codebase and say "figure it out." Each AI task receives a specific file, a specific change description, examples of the correct transformation, and constraints on what it's allowed to modify. The output is validated against the AST, checked for syntax correctness, and then verified by the full build-and-test pipeline. The AI is a tool in the pipeline — not the pipeline itself.

What makes Ovvoc different from Dependabot and Renovate

Dependabot is the baseline. It watches your dependencies, bumps the version number in package.json, regenerates the lockfile, and opens a PR. If the version bump introduces a breaking change, the PR will fail your CI. Dependabot's job is done at that point — it notified you that an update exists. The actual migration work is yours.

Renovate adds meaningful improvements on top of that model. It groups related updates, schedules them to avoid noise, supports monorepos, and handles lockfile maintenance more intelligently. But when it comes to breaking changes, Renovate faces the same fundamental limitation: it bumps versions, it doesn't fix code. If Express 5 changes your routing syntax, Renovate opens a PR that breaks your build and leaves you to figure out the migration.

Ovvoc does the actual migration work. When Express 4 becomes Express 5, Ovvoc doesn't just bump the version — it rewrites your wildcard routes, updates your deprecated method calls, adjusts your TypeScript types, rebuilds the project, runs your test suite, and only then opens a PR. The PR you receive has already been verified to compile, pass tests, and correctly implement the migration. You review a working change, not a broken one.

Early access pricing

Ovvoc uses a simple monthly subscription. Pick a plan based on how many repositories you need monitored — every plan includes all 25 update categories, breaking change resolution, and isolated container builds. There's no free tier and no investor-subsidized pricing.

Early customers receive discounted rates in exchange for case studies and feedback. If you're willing to share your experience with Ovvoc (anonymized or not, your choice), we'll offer a meaningful discount on your first six months. This helps us build trust with future customers and helps you save on a tool that pays for itself in developer time saved.

Billing is simple and transparent: a fixed monthly price based on how many repositories you monitor, with everything included — no per-job or per-token charges.

Roadmap preview

npm is our starting point, not our ending point. The architecture is designed to be ecosystem-agnostic, and we have concrete plans for expanding to additional package ecosystems:

  • Python (pip/poetry) — the second-largest package ecosystem, with its own set of migration challenges around Python version compatibility and dependency resolution
  • Go modules — Go's strict versioning makes some updates easier, but major version bumps with import path changes still require code modifications
  • Rust (cargo) — the Rust ecosystem moves fast, and Cargo's semver enforcement creates a clean foundation for automated updates

Beyond ecosystem expansion, we're building features that teams have been asking for: custom rule authoring so you can define your own migration rules for internal packages, a team dashboard with role-based access and approval workflows, and Slack notifications for real-time updates on job status. Monorepo support with coordinated cross-package updates is already live.

Ready to stop babysitting package.json? Get started with your first repository today.

Stay up to date

Automate your dependency updates. Start with one repo.