The Dart Linter package defines lint rules that identify and report on “lints” found in Dart code. Linting is performed by the Dart analysis server and the
dartanalyzer commandline tool.
The linter is bundled with the Dart SDK; if you have an updated Dart SDK already, you're done!
Alternatively, if you want to contribute to the linter or examine the source, clone the
linter repo like this:
$ git clone https://github.com/dart-lang/linter.git
The linter gives you feedback to help you catch potential errors and keep your code in line with the published Dart Style Guide. Currently enforceable lint rules (or “lints”) are catalogued here and can be configured via an analysis options file. The linter is run from within the
dartanalyzer command-line tool shipped with the Dart SDK. Assuming you have lints configured in an
analysis_options.yaml file with these contents:
linter: rules: - annotate_overrides - hash_and_equals - prefer_is_not_empty
you could lint your package like this:
$ dartanalyzer --options analysis_options.yaml .
and see any violations of the
prefer_is_not_empty rules in the console. To help you choose the rules you want to enable for your package, we have provided a complete list of rules and a growing list of lints according to the Effective Dart guide. For the lints that are enforced internally at Google, see package:pedantic.
If a specific lint warning should be ignored, it can be flagged with a comment. For example,
// ignore: avoid_as (pm as Person).firstName = 'Seth'
dartanalyzer to ignore this instance of
avoid_as warning. As lints are treated the same as errors and warnings by the analyzer, their severity can similarly be configured in an options file. For example, an analysis options file that specifies
linter: rules: - avoid_as analyzer: errors: avoid_as: error
tells the analyzer to treat
avoid_as lints as errors. For more on configuring analysis see the analysis option file docs.
Please file feature requests and bugs in the issue tracker.