Execute `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.

Analyzing and Fixing Dart Code Contents [Analysis Configuration]( analysis configuration) [Diagnostic Suppression]( diagnostic suppression) [Workflow: Executing Static Analysis]( workflow executing static analysis) [Workflow: Applying Automated Fixes]( workflow applying automated fixes) [Examples]( examples) Analysis Configuration Configure the Dart analyzer using the analysis options.yaml file located at the package root. Base Configuration: Always include a standard rule set (e.g., package:lints/recommended.yaml or package:flutter lints/flutter.yaml ) using the include: directive. 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 . 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. Formatter Configuration: Configure dart format behavior under the formatter: node. Set page width (default 80) and trailing commas ( automate or preserve ). 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 . Diagnostic Suppression When a diagnostic (lint or warning) yields a false positive or applies to generated code, suppress it explicitly. 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. 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. Line level Suppression: Add // ignore: <diagnostic code on the line directly above the offending code, or appended to the end of the offending line. Pubspec Suppression: Add ignore: <diagnostic code above the offending line in pubspec.yaml files (e.g., ignore: sort pub dependencies ). Plugin Diagnostics: Prefix the diagnostic code with the plugin name when suppressing plugin specific issues (e.g., // ignore: some plugin/some code ). Workflow: Executing Static Analysis Use this workflow to identify type related bugs, style violations, and potential runtime errors. Task Progress: [ ] 1. Verify analysis options.yaml exists at the project root. [ ] 2. Run the analyzer using the analyze files MCP tool (if available) or the CLI command dart analyze <target directory . [ ] 3. Review the diagnostic output. [ ] 4. If info level issues must be treated as failures, append the fatal infos flag. [ ] 5. Resolve reported errors manually or proceed to the Automated Fixes workflow. Workflow: Applying Automated Fixes Use this workflow to resolve outdated API usages, apply quick fixes, and migrate code (e.g., Dart 3 migrations). Task Progress: [ ] 1. Execute a dry run to preview proposed changes using the dart fix MCP tool or CLI command dart fix dry run . [ ] 2. Review the proposed fixes to ensure they align with the intended architecture. [ ] 3. If additional fixes are required, verify that the corresponding linter rules are enabled in analysis options.yaml . [ ] 4. Apply the fixes using the dart fix MCP tool or CLI command dart fix apply . [ ] 5. Format the modified code using the dart format MCP tool or CLI command dart format . . [ ] 6. Run the static analysis workflow to verify all diagnostics are resolved. Examples Comprehensive analysis options.yaml Inline Diagnostic Suppression

dart-run-static-analysis