In Dart's `dart pub outdated` output, what do the Current, Upgradable, Resolvable and Latest columns mean, and which command closes each gap?
answer
- Current comes from the lockfile
- Upgradable: inside your constraints
- Resolvable: constraints unbounded
- Latest: newest published
- leftmost non-red column
basics
~20 sCurrent is the locked version, Upgradable the newest your constraints allow, Resolvable the newest that works with everything else if constraints were unbounded, and Latest the newest published. pub upgrade closes Current-to-Upgradable; a constraint edit closes Upgradable-to-Resolvable.
solid answer
~40 s`dart pub outdated` lists out-of-date dependencies with four columns. **Current** is the version in `pubspec.lock`. **Upgradable** is the newest version your `pubspec.yaml` allows, which is what `dart pub upgrade` would resolve. **Resolvable** is the newest version that works with all your other dependencies if your own constraints were unbounded. **Latest** is the newest published version. The gaps tell you what to do: Current below Upgradable, run `dart pub upgrade`; Upgradable below Resolvable, raise the constraint (by hand or `dart pub upgrade --major-versions`); Resolvable below Latest, another package is holding it back, which `dart pub deps` reveals. Transitive dependencies are hidden unless you pass `--transitive`.
code
bash · 10 lines$ dart pub outdated
Package Name Current Upgradable Resolvable Latest
direct dependencies:
args 1.4.4 1.6.0 1.6.0 1.6.0
http 0.11.3 0.11.3 0.12.1 0.12.1
path 1.6.2 1.6.2 1.6.2 1.7.0
# args: run dart pub upgrade
# http: raise the constraint to ^0.12.1, then upgrade
# path: held back by another package; find it with dart pub depsgo deeper
Know the four column names and that plain dart pub upgrade moves you to the Upgradable column.
Explain what limits each column and match every gap to its fix: upgrade, constraint edit, or chasing a blocking package.
Run outdated as a routine, schedule major bumps from the Resolvable column, and use --transitive and --no-dev-dependencies to find real blockers.
Turn outdated reports into a tracked dependency-health process with owners for blocked upgrades across many packages.
## What the command is for `dart pub outdated` reports which dependencies are behind and **why**, so you know whether an upgrade is one command, a pubspec edit, or blocked by someone else. It works for apps and packages; if the lockfile is not committed, run `dart pub get` first. ## The four columns | Column | Meaning | Source of the limit | |---|---|---| | **Current** | version recorded in `pubspec.lock` (`-` if not locked) | the last get or upgrade | | **Upgradable** | newest version allowed by your `pubspec.yaml` constraints | your constraints | | **Resolvable** | newest version that resolves with all other dependencies if your constraints were unbounded (`-` if the package would no longer be needed) | other packages' constraints | | **Latest** | newest published version (prereleases handled by `--prereleases`) | the repository | dart.dev's reading tip: look for the **leftmost column with a non-red value** in the coloured terminal output; that is how far you can get and with what. ## Closing each gap 1. **Current < Upgradable.** Your constraints already allow a newer version; the lockfile is just old. Run `dart pub upgrade` (or `dart pub upgrade <name>`). 2. **Upgradable < Resolvable.** Your own constraint is the limit, usually an upper bound before a new major. Raise it to the Resolvable version with caret syntax, for example from `^0.11.0` to `^0.12.1`, then run `dart pub upgrade`. `dart pub upgrade --major-versions` does this for every such package at once; commit first, and read changelogs, because these are likely breaking releases. 3. **Resolvable < Latest.** Another package's constraints hold it back. Run `dart pub deps -s list` and search for the package to see which dependency requires the older version; the fix is upgrading or replacing that dependency. Afterwards, run `dart pub outdated` again. dart.dev's example ends with "Dependencies are all on the latest resolvable versions. Newer versions, while available, are not mutually compatible", which means only the third kind of gap is left. ## Useful options - `--transitive` includes transitive dependencies, which are hidden by default. - `--up-to-date` also lists packages that are current. - `--no-dev-dependencies` resolves as if dev dependencies were absent, which shows what is really holding back runtime packages. - `--no-dependency-overrides` ignores `dependency_overrides`, showing whether an override is still masking a problem. - `--json` produces machine-readable output for a scheduled job. ## A routine that works - Run `dart pub outdated` on a schedule, not only when something breaks. - Apply Upgradable gaps freely with tests; they stay within your declared ranges. - Treat Resolvable gaps as planned work, one major at a time. - Record Latest gaps you cannot close, with the package that blocks them, and revisit them when that package releases.
- In `dart pub outdated`, a package shows Resolvable equal to Current but Latest is higher. What do you do?Nothing in your own pubspec will help: another dependency's constraints hold it back. Use `dart pub deps -s list` to find which package requires the older version, then upgrade or replace that package, or wait for its maintainers to widen the constraint.
- Why might `dart pub outdated` show no problems while a transitive package is years old?By default it hides transitive dependencies. Run it with `--transitive` to include them; any gap you see there is closed by upgrading the direct dependency that pulls the transitive package in.
saying these in an interview costs you the question
- Upgradable is the newest version published on pub.dev
- Resolvable means dart pub upgrade will reach it without edits
- Current comes from pubspec.yaml rather than pubspec.lock
- A Latest gap can always be closed by editing your own constraints
- pub outdated lists transitive dependencies by default