skip to content

In a Flutter app, what does flutter pub get do beyond dart pub get, and which flutter pub subcommands simply forward to pub?

level: middleimportance: should knowfreq 36%

answer

  1. same bundled Dart, same resolver
  2. FLUTTER_ROOT passed to pub
  3. get, upgrade, add, remove post-process
  4. plugin list and platform files
  5. deps, outdated, run just forward

basics

~20 s

flutter pub runs the Dart SDK bundled with Flutter as dart pub, so resolution is identical. After get, upgrade, add and remove it also regenerates the plugin list and platform tooling; other subcommands forward unchanged.

solid answer

~40 s

`flutter pub` is a wrapper: it runs `pub` from the Dart SDK bundled in the Flutter SDK, passing `FLUTTER_ROOT` so `sdk: flutter` dependencies resolve against this SDK. Resolution itself is identical to `dart pub`. The difference is post-processing: after `get`, `upgrade`, `add` and `remove`, the Flutter tool regenerates the project's platform-specific tooling — the `.flutter-plugins-dependencies` plugin list, plugin registrants and generated platform files — and runs localization generation when the pubspec enables it. Subcommands such as `deps`, `outdated`, `downgrade`, `run`, `cache`, `global` and `publish` forward straight to pub. Running `dart pub get` in a Flutter app therefore resolves the same packages but skips that post-processing, which the next `flutter run` or `flutter build` performs anyway.

code

bash · 4 lines
bash
flutter pub add shared_preferences   # resolve, then refresh plugin list and platform files
flutter pub get                      # same post-processing after resolving
flutter pub outdated                 # forwarded to pub unchanged
flutter pub deps --style=compact     # forwarded to pub unchanged

go deeper

for a junior

Use flutter pub get and flutter pub add in Flutter projects, and know they call pub underneath.

for a middle

Explain which subcommands post-process, what regenerating platform tooling means, and why resolution is identical to dart pub.

for a senior

Diagnose stale plugin registration or a mismatched Dart after dependency changes, and keep scripts on flutter pub for Flutter packages.

for a principal

Set conventions for dependency commands across Flutter apps and pure Dart packages in one repository so tooling stays consistent.

## Why a wrapper exists Flutter apps depend on packages from pub like any Dart project, plus two things plain Dart does not know about: the **Flutter SDK** itself (`flutter: sdk: flutter` in `pubspec.yaml`) and **plugins**, packages with native code that each platform project must register. `flutter pub` reuses pub for the first part and adds the Flutter-specific steps for the second. ## What flutter pub actually runs - The executable is the **Dart SDK bundled with this Flutter**, `bin/cache/dart-sdk/bin/dart pub`, so the pub version always matches the SDK. - The environment carries **`FLUTTER_ROOT`**, pointing at the running SDK, so SDK dependencies resolve against it. - The **resolver and lock-file rules are pub's own**; `flutter pub` changes none of them. ## The two kinds of subcommand | Kind | Subcommands | What the Flutter tool adds | |---|---|---| | Resolving | `get`, `upgrade`, `add`, `remove` | post-processing after pub finishes | | Forwarded | `deps`, `outdated`, `downgrade`, `run`, `cache`, `global`, `publish`, `version`, `uploader`, `login`, `logout`, `token` | nothing; arguments go straight to pub | There is also `flutter pub pub <args>`, a passthrough for anything else, and `flutter packages` as an older alias of `flutter pub`. ## The post-processing After a resolving subcommand succeeds, for each root package that depends on Flutter: 1. **Localization generation** runs when `pubspec.yaml` sets `flutter: generate: true`. 2. **Platform-specific tooling is regenerated**: - the **plugin list**, `.flutter-plugins-dependencies`, recording which plugins apply to which platform; - **plugin registrants** and generated files for each platform folder present in the project; - an `analysis_options.yaml` migration where needed. 3. The same happens for an `example/` app when the package has one. This is why adding a plugin with `flutter pub add` makes it usable on the next run without further steps. ## flutter pub versus dart pub in a Flutter app - **Resolution** — identical in both. - **Plugin and platform files** — only `flutter pub` refreshes them immediately. After `dart pub get`, they may be stale until the next `flutter run` or `flutter build`, which regenerates them. - **Tooling that reads the plugin list without building** — may see the old list after `dart pub get`. - **Which Dart** — `dart` on `PATH` may not be the bundled Dart if another SDK comes first; `flutter pub` always uses the bundled one. The practical rule: in a Flutter project, use `flutter pub` for anything that changes dependencies. ## Other places pub runs implicitly - `flutter create` runs `pub get` unless `--no-pub` is passed. - `flutter run`, `flutter build` and `flutter test` run `pub get` automatically by default; `--no-pub` turns that off. - `flutter upgrade` runs a pub upgrade for the project enclosing the current directory. ## A worked example A developer adds a plugin with `dart pub add` instead of `flutter pub add`. The dependency lands in `pubspec.yaml` and the lock file exactly as it would have, but `.flutter-plugins-dependencies` and the generated registrants still describe the old dependency set until something runs Flutter's post-processing. Tools that read those files before the next `flutter run` or `flutter build`, such as a native IDE opened on the platform project, can see the stale list. Running `flutter pub get` regenerates them. Nothing was wrong with the resolution; only the Flutter-specific step had not run yet. The reverse case is harmless: running `flutter pub outdated` or `flutter pub deps` works the same as the `dart pub` form, because those subcommands only forward to pub. ## Summary - Resolution: pub's, identical under both commands. - Post-processing: Flutter's, only after `get`, `upgrade`, `add` and `remove`. - Dart version: always the bundled one under `flutter pub`.

  • Is it wrong to run dart pub get in a Flutter project?
    Not wrong: it resolves exactly the same packages. It skips Flutter's post-processing, so plugin registrants and the plugin list may be stale until the next `flutter run` or `flutter build` regenerates them. Also make sure `dart` on `PATH` is the one bundled with Flutter.
  • Why does flutter pub pass FLUTTER_ROOT to pub?
    A Flutter app depends on `flutter: sdk: flutter`, and SDK packages must resolve against a real SDK location. Passing `FLUTTER_ROOT` points pub at the SDK that is running the command, so the framework, `flutter_test` and other SDK packages come from the right version.

saying these in an interview costs you the question

  • Thinks flutter pub uses a different dependency resolver from dart pub
  • Believes flutter pub outdated adds Flutter-specific analysis
  • Says dart pub get cannot resolve a Flutter project at all
  • Expects a new plugin to need manual native registration after flutter pub add
  • Assumes dart on PATH is always the Dart bundled with Flutter