In Dart and Flutter, what are the lints package's core and recommended sets and flutter_lints, and which does a new Flutter app include?

## What a lint set is The Dart **analyzer** reads a file named `analysis_options.yaml` at the root of a package. One of the things that file can do is switch on **linter rules**: small checks that flag code which compiles but is likely to be wrong, hard to read, or out of line with Effective Dart. There are hundreds of rules, and many of them disagree with each other on purpose (for example `prefer_single_quotes` and `prefer_double_quotes`). Picking rules one by one is tedious, so the Dart and Flutter teams publish curated **rule sets** as ordinary pub packages. A rule set is just a YAML file that lists rules; your project pulls it in with the `include:` key. ## The two sets in package:lints The `lints` package contains two files: - **`package:lints/core.yaml`**: rules for critical issues that are likely to cause problems when code runs or is consumed by others. Examples include `avoid_empty_else`, `await_only_futures`, `empty_catches`, `hash_and_equals`, `no_duplicate_case_values` and `unrelated_type_equality_checks`. The dart.dev docs say all code should pass these, and pub.dev's package score is based in part on them. - **`package:lints/recommended.yaml`**: its first line is `include: package:lints/core.yaml`, so it is a **superset** of core. It adds rules that catch further problems and enforce a single idiomatic style, such as `prefer_final_fields`, `unnecessary_this`, `unnecessary_new` and `use_super_parameters`. The Dart team recommends it for all Dart code. ## flutter_lints on top For Flutter code the recommendation is **`flutter_lints`**, not `lints` directly. Its `flutter.yaml` begins with `include: package:lints/recommended.yaml` and adds rules that only make sense in a widget codebase: | Rule | What it flags | |---|---| | `avoid_print` | `print` calls left in app code | | `use_build_context_synchronously` | a `BuildContext` used across an `await` without a mounted check | | `use_key_in_widget_constructors` | public widget constructors without a `key` parameter | | `sized_box_for_whitespace` | a `Container` used only for spacing | | `sort_child_properties_last` | `child`/`children` not passed as the last argument | | `avoid_web_libraries_in_flutter` | web-only libraries imported in a Flutter package | So the chain is **core → recommended → flutter**, each file including the one before it. ## What a new project gets When you run `flutter create`, the app template: 1. adds `flutter_lints` to `dev_dependencies` in `pubspec.yaml` (the Flutter 3.47 template pins `^6.0.0`); 2. writes an `analysis_options.yaml` whose first real line is `include: package:flutter_lints/flutter.yaml`; 3. adds an `analyzer: exclude:` list for `build/**` and the platform folders it generated (`android/**`, `ios/**` and so on); 4. leaves an empty `linter: rules:` section with comments showing how to switch individual rules on or off. A pure Dart package or CLI does the equivalent by hand: ```yaml # pubspec.yaml: dart pub add --dev lints # analysis_options.yaml include: package:lints/recommended.yaml ``` ## Why the set is a dev dependency, and what upgrades do The rule set is only read by tooling (IDEs, `dart analyze`), never compiled into the app, so it belongs in `dev_dependencies`. Because it is a versioned package, **upgrading it can change your results**: a new release may add rules to core or recommended, or remove low-value ones. The dart.dev guide warns that code which previously passed analysis might start failing after a new `lints` version. Teams handle this by upgrading deliberately, fixing the new findings (often with `dart fix`), or switching an unwanted new rule off in their own options file. ## Common confusions - The sets do not change the **compiler**. A lint finding never stops `flutter run` or `dart compile`; it only shows up in analysis output. - Including a set is not the same as enabling every rule that exists. Most rules are opt-in and live in no set at all. - `recommended` is not a stricter version of `core` with raised severities; it is core **plus more rules**. - Your own `analysis_options.yaml` still wins. Anything you set locally overrides what the included file says. ## Choosing a set for each kind of package A repository often holds more than one kind of package, and each can include a different set: - **A Flutter app or Flutter plugin**: `package:flutter_lints/flutter.yaml`, as the template writes it. - **A pure Dart library shared by several apps**: `package:lints/recommended.yaml`, since widget rules do not apply and a lighter dev dependency is enough. - **A command-line tool or server written in Dart**: also `recommended`; `avoid_print` would be wrong there, because printing is the tool's job. - **A team with extra conventions**: a local file that includes one of the above and then adds rules, or a shared options file that every package includes by relative path. Whatever the choice, the set is the **starting point**, not the finished policy. Interviewers usually follow up by asking which rules you added and why.