$npx -y skills add flutter/agent-plugins --skill dart-run-static-analysisExecute dart analyze to identify warnings and errors, and use dart fix --apply to automatically resolve mechanical lint issues. Use during development to ensure code quality and before committing changes.
| 1 | # Analyzing and Fixing Dart Code |
| 2 | |
| 3 | ## Contents |
| 4 | - [Analysis Configuration](#analysis-configuration) |
| 5 | - [Diagnostic Suppression](#diagnostic-suppression) |
| 6 | - [Workflow: Executing Static Analysis](#workflow-executing-static-analysis) |
| 7 | - [Workflow: Applying Automated Fixes](#workflow-applying-automated-fixes) |
| 8 | - [Examples](#examples) |
| 9 | |
| 10 | ## Analysis Configuration |
| 11 | |
| 12 | Configure the Dart analyzer using the `analysis_options.yaml` file located at the package root. |
| 13 | |
| 14 | - **Base Configuration:** Always include a standard rule set (e.g., `package:lints/recommended.yaml` or `package:flutter_lints/flutter.yaml`) using the `include:` directive. |
| 15 | - **Strict Type Checks:** Enable strict type checks under the `analyzer: language:` node to prevent implicit downcasts and dynamic inferences. Set `strict-casts: true`, `strict-inference: true`, and `strict-raw-types: true`. |
| 16 | - **Linter Rules:** Explicitly enable or disable specific rules under the `linter: rules:` node. Use a key-value map (`rule_name: true/false`) when overriding included rules, or a list (`- rule_name`) when defining a fresh set. Do not mix list and map syntax in the same `rules` block. |
| 17 | - **Formatter Configuration:** Configure `dart format` behavior under the `formatter:` node. Set `page_width` (default 80) and `trailing_commas` (`automate` or `preserve`). |
| 18 | - **Analyzer Plugins:** Enable custom diagnostics by adding plugins under the `analyzer: plugins:` node. Ensure the plugin package is added as a `dev_dependency` in `pubspec.yaml`. |
| 19 | |
| 20 | ## Diagnostic Suppression |
| 21 | |
| 22 | When a diagnostic (lint or warning) yields a false positive or applies to generated code, suppress it explicitly. |
| 23 | |
| 24 | - **File-level Exclusion:** Use the `analyzer: exclude:` node in `analysis_options.yaml` to exclude entire files or directories (e.g., `**/*.g.dart`) using glob patterns. |
| 25 | - **File-level Suppression:** Add `// ignore_for_file: <diagnostic_code>` at the top of a Dart file to suppress specific diagnostics for the entire file. Use `// ignore_for_file: type=lint` to suppress all linter rules. |
| 26 | - **Line-level Suppression:** Add `// ignore: <diagnostic_code>` on the line directly above the offending code, or appended to the end of the offending line. |
| 27 | - **Pubspec Suppression:** Add `# ignore: <diagnostic_code>` above the offending line in `pubspec.yaml` files (e.g., `# ignore: sort_pub_dependencies`). |
| 28 | - **Plugin Diagnostics:** Prefix the diagnostic code with the plugin name when suppressing plugin-specific issues (e.g., `// ignore: some_plugin/some_code`). |
| 29 | |
| 30 | ## Workflow: Executing Static Analysis |
| 31 | |
| 32 | Use this workflow to identify type-related bugs, style violations, and potential runtime errors. |
| 33 | |
| 34 | **Task Progress:** |
| 35 | - [ ] 1. Verify `analysis_options.yaml` exists at the project root. |
| 36 | - [ ] 2. Run the analyzer using the `analyze_files` MCP tool (if available) or the CLI command `dart analyze <target_directory>`. |
| 37 | - [ ] 3. Review the diagnostic output. |
| 38 | - [ ] 4. If info-level issues must be treated as failures, append the `--fatal-infos` flag. |
| 39 | - [ ] 5. Resolve reported errors manually or proceed to the Automated Fixes workflow. |
| 40 | |
| 41 | ## Workflow: Applying Automated Fixes |
| 42 | |
| 43 | Use this workflow to resolve outdated API usages, apply quick fixes, and migrate code (e.g., Dart 3 migrations). |
| 44 | |
| 45 | **Task Progress:** |
| 46 | - [ ] 1. Execute a dry run to preview proposed changes using the `dart_fix` MCP tool or CLI command `dart fix --dry-run`. |
| 47 | - [ ] 2. Review the proposed fixes to ensure they align with the intended architecture. |
| 48 | - [ ] 3. If additional fixes are required, verify that the corresponding linter rules are enabled in `analysis_options.yaml`. |
| 49 | - [ ] 4. Apply the fixes using the `dart_fix` MCP tool or CLI command `dart fix --apply`. |
| 50 | - [ ] 5. Format the modified code using the `dart_format` MCP tool or CLI command `dart format .`. |
| 51 | - [ ] 6. Run the static analysis workflow to verify all diagnostics are resolved. |
| 52 | |
| 53 | ## Examples |
| 54 | |
| 55 | ### Comprehensive `analysis_options.yaml` |
| 56 | |
| 57 | ```yaml |
| 58 | include: package:flutter_lints/recommended.yaml |
| 59 | |
| 60 | analyzer: |
| 61 | exclude: |
| 62 | - "**/*.g.dart" |
| 63 | - "lib/generated/**" |
| 64 | language: |
| 65 | strict-casts: true |
| 66 | strict-inference: true |
| 67 | strict-raw-types: true |
| 68 | errors: |
| 69 | todo: ignore |
| 70 | invalid_assignment: warning |
| 71 | missing_return: error |
| 72 | |
| 73 | linter: |
| 74 | rules: |
| 75 | avoid_shadowing_type_parameters: false |
| 76 | await_only_futures: true |
| 77 | use_super_parameters: true |
| 78 | |
| 79 | formatter: |
| 80 | page_width: 100 |
| 81 | trailing_commas: preserve |
| 82 | ``` |
| 83 | |
| 84 | ### Inline Diagnostic Suppression |
| 85 | |
| 86 | ```dart |
| 87 | // Suppress for the entire file |
| 88 | // ignore_for_file: unused_local_variable, dead_code |
| 89 | |
| 90 | void processData() { |
| 91 | // Suppress for a specific line |
| 92 | // ignore: invalid_assignment |
| 93 | int x = ''; |
| 94 | |
| 95 | const y = 10; // ignore: |