In a Dart pubspec.yaml, when would you use a hosted, git, path or sdk dependency source, and which ones block publishing to pub.dev?
answer
- hosted is the default
- git url, ref, path
- tag_pattern since 3.9
- path deps are live symlinks
- sdk: flutter
basics
~20 sHosted, the default, fetches versions from pub.dev or another pub server; git pins a repository, branch, tag or commit; path uses a live local directory; sdk: flutter takes a package bundled with Flutter. Git and path dependencies cannot be published to pub.dev.
solid answer
~40 sA bare `http: ^1.2.0` is **hosted** from pub.dev; `hosted: <url>` points the same dependency at a private pub server. **Git** takes a clone URL plus optional `ref` (branch, tag or commit) and `path` inside the repo, and since Dart 3.9 a `tag_pattern` with a version constraint lets the solver choose among tagged releases. **Path** points at a local directory; pub links to its `lib/` so edits show up immediately, which suits developing an app and a package side by side. **SDK** (`sdk: flutter`) takes packages shipped with Flutter, such as `flutter_test`. A package with git or path dependencies cannot be uploaded to pub.dev, so the workflow is: path while developing, hosted once the dependency is published.
code
yaml · 13 linesdependencies:
flutter:
sdk: flutter
http: ^1.2.0 # hosted on pub.dev
company_auth:
hosted: https://pub.internal.example
version: ^2.1.0 # private pub server
charts_fork:
git:
url: https://github.com/example/charts.git
ref: fix-axis-labels # branch, tag or commit
shared_ui:
path: ../shared_ui # live local packagego deeper
Know the four sources, that hosted pub.dev is the default, and that flutter_test is declared with sdk: flutter.
Explain git ref and path, how path dependencies stay live, how the lockfile pins git commits, and what blocks publishing.
Keep git and path sources temporary in shared code, preferring a private hosted server or tag_pattern for repeatable releases.
Decide how internal packages are distributed, weighing a private pub server against git sources and a monorepo.
## Four places pub can get a package Each dependency has a **source** that tells pub where to find it. When you write only a name and a constraint, the source is **hosted** on pub.dev. | Source | Syntax sketch | Typical use | Publishable to pub.dev? | |---|---|---|---| | hosted (default) | `http: ^1.2.0` | released packages | yes | | git | `git: {url, ref, path}` | unreleased fixes, forks | no | | path | `path: ../shared_ui` | editing two packages together | no | | sdk | `sdk: flutter` | Flutter's bundled packages | yes | ## Hosted A hosted dependency is downloaded from pub.dev, or from any HTTP server that speaks the same API. To use your own repository, nest `hosted:` with the server URL and put the constraint under `version:`. A missing constraint means `any`, which dart.dev discourages. ## Git ```yaml dependencies: kittens: git: url: [email protected]:example/cats.git ref: fix-null-crash path: packages/kittens ``` - `url` is anything `git clone` accepts, including SSH URLs; pub shells out to `git`, so private repos work with your normal Git credentials. - `ref` pins a branch, tag or commit; `path` locates the package inside a repository that holds several. - Since **Dart 3.9**, `tag_pattern: v{{version}}` plus a `version:` constraint makes pub treat matching tags as versions and **solve** among them, which requires the depending pubspec to have an SDK lower bound of 3.9 or higher. - Since Dart 3.12, git dependencies support Git LFS. The resolved commit is recorded in `pubspec.lock`, so a branch `ref` does not drift until you upgrade. ## Path A path dependency points at a directory, absolute or relative to the pubspec. Pub links straight to that package's `lib/`, so **changes are visible immediately** without re-running pub. It is the tool for building an app and a package it uses at the same time. dart.dev's workflow: 1. Depend on the package by path while you work on both. 2. Publish the dependency once it works. 3. Switch the pubspec back to the hosted version. 4. Publish the main package, if it is published at all. ## SDK `sdk: flutter` is satisfied only when pub runs inside the `flutter` tool and the Flutter SDK contains the named package. It is how `flutter`, `flutter_test`, `integration_test` and `flutter_localizations` are declared. Flutter is currently the only supported SDK source; an unknown SDK name is never satisfied. ## Publishing rules - pub.dev rejects packages with **path** dependencies, since nobody else can reach your file system. - **Git** dependencies are not allowed for packages uploaded to pub.dev either. - Apps with `publish_to: 'none'` can use any source. ## Package descriptors on the command line `dart pub add` accepts the same sources in flow-style YAML: `dart pub add foo:'{git: https://github.com/example/foo}'` or `dart pub add 'foo:{path: ../foo}'`.
- In a pubspec, a git dependency uses `ref: main`. Does every `dart pub get` pull the latest commit on main?No. The resolved commit is written to `pubspec.lock`, and `dart pub get` keeps it. The dependency moves to a newer commit only when you upgrade it, for example with `dart pub upgrade charts_fork`.
- What does `tag_pattern` add to a git dependency in a Dart 3.9+ pubspec?It tells pub which tags mark releases, such as `v{{version}}`. With a `version:` constraint alongside it, pub lists the matching tags and feeds them to the solver as versions, so a git dependency can be version-solved like a hosted one.
saying these in an interview costs you the question
- A path dependency needs pub get after every edit to the other package
- pub.dev accepts git dependencies if the repository is public
- sdk: flutter works when running plain dart pub get
- A git ref on a branch silently changes on every pub get
- Git dependencies can never be version-solved