Q: Which checks would you put in a CI pipeline for a Dart package?

Give the list in order, with the reason for each step — the easiest way to sound experienced. 1. dart pub get — deterministic install from the lock file. 2. dart format --output=none --set-exit-if-changed . — removes formatting debates from code review; CI reports the mismatch instead of rewriting code. 3. dart analyze --fatal-infos — type errors and lints; without --fatal-infos, warnings accumulate for years. 4. dart test --coverage=coverage — tests plus a coverage report as an artifact. 5. For a published package: dart pub publish --dry-run (catches packaging mistakes) and a periodic dart pub outdated. Details worth adding (a senior signal): a matrix build across the lowest supported SDK and stable, because the environment: sdk: field only means something if it is actually exercised. Caching the pub cache in CI (a noticeable build-time win). And explicitly not running dart fix --apply in CI — CI should surface the problem, not fix the code.

Q: dart pub get fails with a version conflict. How do you resolve it?

Structure it as diagnosis → options → last resort. Diagnosis: pub's error message is genuinely readable — it names the two constraints that contradict each other. I open the tree with dart pub deps --style=tree to see whether the conflict is transitive: very often the problem is not in a direct dependency but in one of its dependencies. Options, in this order: 1. Loosen my own constraints: widen ^1.4.2 to the range actually supported, or move an old package to a new major with dart pub upgrade --major-versions. 2. Update the stale package — the real cause is usually one dependency nobody has bumped for months. 3. Re-examine the need: sometimes the offending package is not required at all, and dropping it is the cheapest fix. Last resort: dependency_overrides does get past the conflict, but it creates an unverified combination — pub's guarantee is gone and the mismatch may only surface at runtime. So I always add a comment plus a ticket and treat it as temporary; in a published package I never ship one. Prevention: keep packages aligned across a monorepo, upgrade dependencies in small regular steps instead of one two-year jump, and run dart pub outdated weekly.

Q: How would you enforce a team code standard with analysis_options.yaml?

Lead with the core message: a standard should be a tool, not a discussion. A team arguing about style in code review is burning time; the analyzer does the same job for free and without emotion. How I set it up: A base set: include: package:lints/recommended.yaml for packages, package:flutter_lints/flutter.yaml for Flutter apps. Writing a rule list from scratch is pointless. Then the team's specific rules — unawaited_futures, avoid_dynamic_calls, require_trailing_commas — each one born from a real incident, not added "just in case". Raise the severity of the important ones from warning to error in the analyzer: errors: section, and run CI with --fatal-infos. In a monorepo, keep a root analysis_options.yaml and include it from each package — duplicated configuration drifts. How I roll it out (the part usually skipped): dropping a strict set onto an existing project produces 3000 warnings that everyone then learns to ignore. So it goes rule by rule: enable one → dart fix --apply for the mechanical part → fix the rest by hand → make it blocking in CI. When an exception is genuinely needed, it is a narrow // ignore: rule_name with a reason, not the rule's removal from the shared config. Close: "The goal is not to correct people but to move the discussion out of code review and into a configuration file — you agree once and the topic is closed."

Question 1

What is the difference between dependencies and dev_dependencies? What happens if you put one in the wrong place?

Accepted Answer

Direct answer: dependencies are what the package needs to run; dev_dependencies are what you need while working on the package itself (tests, lints, code generation). Why: dev_dependencies are not transitive — someone installing your package does not download them. That keeps the consumer's dependency graph small and reduces version conflicts. Name both failure modes with their consequences: test accidentally in dependencies: everyone using your package pulls a test framework — extra weight and an unnecessary source of conflicts. A runtime package accidentally in dev_dependencies: everything works on your machine (it is installed locally) but the consumer's import fails. CI usually does not catch this, which is why I run dart pub publish --dry-run before publishing. If you want to go deeper: dependency_overrides is a temporary escape hatch and must not ship in a published package — pub honours it only in the root package.

Question 2

What does ^1.2.3 mean, and why does ^0.2.3 behave differently?

Accepted Answer

Start short and precise: ^1.2.3 means >=1.2.3 <2.0.0. The reason is semantic versioning — the major number signals breaking changes, so the caret stops before the next major. Then hit the subtlety, which is why the question is asked at all: before 1.0.0 the API is not considered stable, so pub treats the minor number as major — ^0.2.3 means >=0.2.3 <0.3.0. That prevents surprise breakage on 0.x packages. Add the practice: in a library I always use carets and never pin exact versions, because if one package pins 1.4.2 and another 1.4.3, the consumer has no solution. In an application the precision comes from pubspec.lock — constraints stay wide while the lock file guarantees reproducible builds. Close in one sentence: "The constraint says what is allowed, the lock file says what was actually installed."

Question 3

Which checks would you put in a CI pipeline for a Dart package?

Accepted Answer

Give the list in order, with the reason for each step — the easiest way to sound experienced. 1. dart pub get — deterministic install from the lock file. 2. dart format --output=none --set-exit-if-changed . — removes formatting debates from code review; CI reports the mismatch instead of rewriting code. 3. dart analyze --fatal-infos — type errors and lints; without --fatal-infos, warnings accumulate for years. 4. dart test --coverage=coverage — tests plus a coverage report as an artifact. 5. For a published package: dart pub publish --dry-run (catches packaging mistakes) and a periodic dart pub outdated. Details worth adding (a senior signal): a matrix build across the lowest supported SDK and stable, because the environment: sdk: field only means something if it is actually exercised. Caching the pub cache in CI (a noticeable build-time win). And explicitly not running dart fix --apply in CI — CI should surface the problem, not fix the code.

Question 4

dart pub get fails with a version conflict. How do you resolve it?

Accepted Answer

Structure it as diagnosis → options → last resort. Diagnosis: pub's error message is genuinely readable — it names the two constraints that contradict each other. I open the tree with dart pub deps --style=tree to see whether the conflict is transitive: very often the problem is not in a direct dependency but in one of its dependencies. Options, in this order: 1. Loosen my own constraints: widen ^1.4.2 to the range actually supported, or move an old package to a new major with dart pub upgrade --major-versions. 2. Update the stale package — the real cause is usually one dependency nobody has bumped for months. 3. Re-examine the need: sometimes the offending package is not required at all, and dropping it is the cheapest fix. Last resort: dependency_overrides does get past the conflict, but it creates an unverified combination — pub's guarantee is gone and the mismatch may only surface at runtime. So I always add a comment plus a ticket and treat it as temporary; in a published package I never ship one. Prevention: keep packages aligned across a monorepo, upgrade dependencies in small regular steps instead of one two-year jump, and run dart pub outdated weekly.

Question 5

How would you enforce a team code standard with analysis_options.yaml?

Accepted Answer

Lead with the core message: a standard should be a tool, not a discussion. A team arguing about style in code review is burning time; the analyzer does the same job for free and without emotion. How I set it up: A base set: include: package:lints/recommended.yaml for packages, package:flutter_lints/flutter.yaml for Flutter apps. Writing a rule list from scratch is pointless. Then the team's specific rules — unawaited_futures, avoid_dynamic_calls, require_trailing_commas — each one born from a real incident, not added "just in case". Raise the severity of the important ones from warning to error in the analyzer: errors: section, and run CI with --fatal-infos. In a monorepo, keep a root analysis_options.yaml and include it from each package — duplicated configuration drifts. How I roll it out (the part usually skipped): dropping a strict set onto an existing project produces 3000 warnings that everyone then learns to ignore. So it goes rule by rule: enable one → dart fix --apply for the mechanical part → fix the rest by hand → make it blocking in CI. When an exception is genuinely needed, it is a narrow // ignore: rule_name with a reason, not the rule's removal from the shared config. Close: "The goal is not to correct people but to move the discussion out of code review and into a configuration file — you agree once and the topic is closed."

Constraint	What it allows	Note
`^1.4.2`	`>=1.4.2 <2.0.0`	The default choice: new features and fixes arrive, breaking changes do not
`^0.3.1`	`>=0.3.1 <0.4.0`	Before 1.0.0 the minor number counts as breaking — a favourite interview subtlety
`>=1.2.0 <1.5.0`	A manually written range	When there is a concrete reason (a known regression); document it in a comment
`1.4.2`	That exact version only	Effectively forbidden in a library: it forces version conflicts on consumers
`any`	Any version	Dangerous in practice — a future major release can break your package
`path: ../billing_core`	From a local folder	For monorepos and local development; cannot be published
`git: {url: ..., ref: v1.4.2}`	From a repository at a specific ref	Fine for internal packages; pin `ref` to a tag or commit, never a branch

pub, pubspec and the analyzer

📚 Sources and documentation