After moving an app and four packages into one Dart pub workspace, `dart pub get` fails on incompatible `http` majors that built fine separately; why, and what are your options?

## What changed when the packages joined Picture a monorepo with a Flutter app, `apps/field_app`, and four local packages: `core`, `api_client`, `ui_kit` and `storage`. Before it became a pub workspace, every directory had its own `pubspec.yaml` **and its own `pubspec.lock`**. Each package was resolved in isolation: - `field_app` resolved its own dependencies, plus the regular `dependencies` of the packages it imports; - `storage`, which the app did not use yet, resolved separately, with `http: ^0.13.0`; - **`dev_dependencies` of a package were never part of anyone else's resolution**, since pub includes dev dependencies only for the root package being resolved. Turning the repository into a workspace changes that. Its single `pubspec.lock` contains **the resolution of all `dependencies` and `dev_dependencies` of all workspace packages**. Every constraint in every member now has to be satisfied at once. ## Why pub cannot satisfy both A Dart resolution maps each package name to **exactly one version**; Dart doesn't allow multiple versions of the same package. `http: ^0.13.0` means at least 0.13.0 and below 0.14.0, and `http: ^1.2.0` means at least 1.2.0 and below 2.0.0. The ranges do not overlap, so the solver reports that no version of `http` satisfies both members, and `dart pub get` fails for the whole repository. dart.dev presents this as a deliberate trade: a shared resolution raises the risk of conflicts, but for packages meant to be used together that is **useful** - it forces you to fix incompatibilities when they appear, rather than when someone first wires `storage` into the app. ## The options | Option | What it does | When it fits | |---|---|---| | **Migrate the lagging member** | move `storage` to `http` 1.x and raise its constraint | the normal fix | | `dart pub upgrade --major-versions` | rewrites constraints to the latest majors, in **all** workspace pubspecs at once | many members lag behind | | `dependency_overrides` | forces one version for the whole workspace | a short, documented stopgap | | Remove the member from the workspace | it resolves on its own again | the package really is independent and must stay on the old major | ## Overrides inside a workspace Overrides behave differently from a single package: - **All** `dependency_overrides` sections in workspace packages are respected, not only the root's. - A given package may be overridden **only once** in the whole workspace; dart.dev recommends keeping overrides in the root `pubspec.yaml`. - A `pubspec_overrides.yaml` next to any workspace pubspec can also carry overrides, which is handy for local experiments that should not be committed. - An override silences the solver, not the code: if `storage` really calls 0.13-only APIs, forcing `http` 1.x turns a resolution error into a compile error. ## Finding the culprit 1. Read the solver's message: it names the package and the members whose constraints clash. 2. `dart pub deps` in a workspace lists dependencies for all packages, one workspace package at a time, which shows who pulls what. 3. `dart pub outdated` lists dependencies across the workspace and shows which ones have newer majors. 4. Check `dev_dependencies` first: they are the conflicts that never showed up before the move. ## Preventing the next clash The workspace turns version drift into an immediate error, so the habits change as well: - **Upgrade shared dependencies in one change.** `dart pub upgrade` in a workspace moves the shared resolution for every member, and `--major-versions` updates the constraints in all workspace pubspecs, so a major bump lands everywhere together. - **Review `dev_dependencies` like regular ones.** Test helpers, generators and lint packages of every member now share one resolution with the app. - **Keep committed overrides rare and at the root**, each with a comment naming the member being migrated, and delete them when the migration lands. - **Run `dart pub outdated` regularly** at the repository level, so lagging majors are found before a member's upgrade collides with them. - **Question membership.** A package that deliberately follows a different upgrade cadence, such as a tool pinned to an old dependency, is better kept outside the workspace than held in place by overrides. ## Summary - One workspace means one resolution, including every member's dev dependencies. - One version per package name, so non-overlapping constraints fail at `dart pub get`. - Fix the lagging member; use a single root override only as a stopgap; keep genuinely independent packages out.