Practise vocabulary for dependency updates: "upgrade to the latest", reading Renovate and Dependabot pull requests, communicating breaking changes in an upgrade, and reviewing update PRs in professional English.
0 / 5 completed
1 / 5
A Dependabot pull request title reads: 'Bump axios from 0.27.2 to 1.6.8'. Before merging, a developer writes in the review: 'This is a major bump — we need to check for breaking changes.' Why is a major bump treated differently from a patch update?
Under SemVer, incrementing the MAJOR version number signals that the library has made breaking (incompatible) changes. Consumer code may need updates before the new version works correctly. This is why major bump PRs require human review of the migration guide and changelog, unlike patch PRs which can often be auto-merged.
2 / 5
A developer runs 'npm outdated' and sees several packages in the output. What does this command tell them?
'npm outdated' compares installed versions against the registry and shows three columns: Current (installed), Wanted (highest version satisfying your package.json range), and Latest (newest published version). It is the standard starting point for a dependency update session.
3 / 5
In a Renovate configuration file, a team sets 'automerge: true' for devDependencies with a patch update type. What will happen when Renovate opens a patch update PR for eslint?
Automerge in Renovate/Dependabot means: if CI is green, merge without human approval. It is commonly enabled for low-risk updates (patch bumps, devDependencies) to reduce review burden. MAJOR bumps typically keep automerge off so engineers can assess breaking changes.
4 / 5
A PR description from Renovate contains: 'This update includes breaking changes. Please review the migration guide at ...' Which action should the reviewer take first?
When an upgrade PR notes breaking changes, the correct approach is: read the changelog/migration guide, identify affected code in the project, apply necessary changes, confirm CI passes, then merge. 'npm audit fix' addresses security vulnerabilities, not API breaking changes.
5 / 5
During a code review a colleague comments: 'We should upgrade to the latest stable version of this library — the version we're on is two majors behind.' What concern is the colleague raising?
Being multiple major versions behind is a technical debt concern: the team is missing security fixes, performance improvements, and bug fixes. It also means a larger, riskier migration when they eventually do upgrade (e.g. v1 → v3 vs v2 → v3). Keeping dependencies reasonably current reduces this risk.