Update Categories

Ovvoc classifies every dependency update into one of 25 categories across three tiers. The category determines the update strategy: version-only, AST transform, or AI-assisted migration.

Categories 1–6: No code change needed

These updates only require a version bump and lockfile regeneration. No source code modifications. Processed fastest.

Categories 7–13: Simple code transforms

These require deterministic code modifications using AST transforms. Each has a well-defined "before → after" pattern that can be applied automatically.

Categories 14–25: Complex transforms

The hardest category tier. These require multi-file refactoring, architectural understanding, and sometimes AI assistance. This is where Ovvoc's competitive moat lies — no other tool handles these.

How classification works

When Ovvoc detects an update, the scanner checks:

1. Rule database: 150+ YAML rules across 29 packages with known version ranges
2. Changelog metadata: Published release notes and migration guides
3. Registry metadata: Version ranges, deprecation notices

The highest-complexity matching rule determines the primary category. A single update can span multiple categories — for example, Express 4→5 triggers categories 7, 9, 19, 20, and 22 simultaneously.

Learn more about how categories map to pipeline strategies in the Update Pipeline docs.

Code examples by category

Categories 7–13 involve deterministic code transformations — well-defined “before → after” patterns that Ovvoc applies automatically using AST parsing. Here are concrete examples for each:

Category 7: Function/method rename

When a library renames an API method between versions, Ovvoc finds every call site and updates the method name. The AST parser ensures only calls on the correct object are renamed.

• Before: app.del('/items/:id', handler)
• After: app.delete('/items/:id', handler)

This example comes from Express 4 → 5, where the app.del() method was renamed to app.delete() to match the HTTP method name. Ovvoc only renames calls on Express app instances, not unrelated functions that happen to be named del.

Category 8: Import path change

When a package restructures its export paths, Ovvoc updates all import and require statements across your codebase.

• Before: const _ = require('lodash')
• After: const _ = require('lodash-es')

Another common example is subpath changes: import { debounce } from 'lodash/debounce' becoming import { debounce } from 'lodash-es/debounce' when migrating to the ESM-native build of lodash.

Category 9: Parameter signature change

When a function’s parameter order or shape changes, Ovvoc restructures every call site.

• Before: res.json(200, { user })
• After: res.status(200).json({ user })

In Express 5, the two-argument form of res.json(status, body) was removed. Ovvoc detects these patterns and rewrites them to the chained form automatically.

Category 10: Config key rename

When a tool changes its configuration file format or key names, Ovvoc updates your config files.

• Before: .eslintrc.json with legacy keys
• After: eslint.config.js with flat config format

The ESLint 8 → 9 migration is a prime example: the entire configuration format changed from the .eslintrc hierarchy to the flat config system. Ovvoc handles the full restructuring, including moving plugins and rules into the new format.

Category 11: Deprecated API replacement

When APIs are deprecated and replaced with new alternatives, Ovvoc swaps every usage.

• Before: new Buffer('hello')
• After: Buffer.from('hello')

Deprecated APIs like new Buffer(), fs.exists(), and req.host (in Express 5) are replaced with their modern equivalents. The transform preserves all arguments and adapts the calling convention.

Categories 12–13: Export changes

When a package switches from a default export to named exports (or renames a named export), Ovvoc updates all import statements:

• Category 12 — Before: import React from 'react'
• Category 12 — After: import { React } from 'react'
• Category 13 — Before: import { render } from 'react-dom'
• Category 13 — After: import { createRoot } from 'react-dom/client'

How category detection works

Ovvoc uses a three-layer classification system to determine the correct category for every update. Each layer provides increasing coverage:

1. YAML rule matching — the primary classification method. Ovvoc checks whether the package name and version range matches an existing rule file in the database. With 150+ rules across 29 packages, this covers the vast majority of popular npm packages. Rule matching is instant (under 1ms) and fully deterministic.
2. Changelog parsing — for packages not covered by rules, Ovvoc fetches the published release notes and changelog from the npm registry metadata. It scans for breaking change keywords (“BREAKING”, “removed”, “renamed”, “deprecated”) and maps them to the appropriate category range. This layer catches breaking changes in less common packages.
3. AI fallback — when neither rules nor changelog parsing produce a confident classification, Ovvoc delegates to AI. The classifier receives the package changelog, the diff between versions, and the project’s usage patterns, then returns a category prediction with a confidence score. This is budget-controlled and validated against the known category definitions.

The three layers are evaluated in order. If rule matching produces a result, changelog parsing and AI are skipped entirely. This keeps classification fast and deterministic for the majority of updates.

Multi-category updates

A single dependency update can span multiple categories simultaneously. For example, Express 4 → 5 triggers categories 7 (function rename: app.del), 9 (parameter change: res.json), 19 (syntax change: wildcards), 20 (removed feature: Connect middleware), and 22 (type system change: req.params).

When multiple categories apply, Ovvoc selects the highest category number as the primary category. This determines the overall strategy:

• If the highest category is 1–6, the strategy is version-only (no code changes)
• If the highest category is 7–13, the strategy is AST transform (deterministic code changes)
• If the highest category is 14–25, the strategy is AI-assisted (deterministic + AI where needed)

All relevant rules from all matching categories are applied, not just the primary one. The strategy escalation ensures that the pipeline uses the appropriate level of sophistication for the most complex change in the update.

Success rates

Based on Ovvoc’s 100-repo test suite, here are the observed success rates by category tier:

When Ovvoc cannot achieve a successful update, it generates a detailed failure report instead of a broken pull request. Your main branch is never affected by failed updates. See the Update Pipeline docs for details on failure handling.