dart-resolve-package-conflictslisted

# Managing Dart Dependencies ## Contents - [Core Concepts](#core-concepts) - [Version Constraints](#version-constraints) - [Workflow: Auditing Dependencies](#workflow-auditing-dependencies) - [Workflow: Upgrading Dependencies](#workflow-upgrading-dependencies) - [Workflow: Resolving Version Conflicts](#workflow-resolving-version-conflicts) - [Examples](#examples) ## Core Concepts Dart enforces a strict single-version rule for dependencies: a project and all its transitive dependencies must resolve to a single, shared version of any given package. This prevents runtime type mismatches but introduces the risk of "version lock." To mitigate version lock, Dart relies on version constraints rather than pinned versions in the `pubspec.yaml`. The `pubspec.lock` file maintains the exact resolved versions for reproducible builds. Understand the output columns of `dart pub outdated`: * **Current:** The version currently recorded in `pubspec.lock`. * **Upgradable:** The latest version allowed by the constraints in `pubspec.yaml`. `dart pub upgrade` resolves to this. * **Resolvable:** The absolute latest version that can be resolved when factoring in all other dependencies in the project. * **Latest:** The latest published version of the package (excluding prereleases). ## Version Constraints * **Use Caret Syntax:** Always use caret syntax (e.g., `^1.2.3`) for dependencies in `pubspec.yaml`. This allows `pub` to select newer, non-breaking versions (up to, but not includi