0.1.44 (#916)

* 0.1.44

# 0.1.44

* new `avoid_relative_lib_imports` lint
* new `unnecessary_parenthesis` lint
* updates to `prefer_const_declarations` to support optional `new` and `const`
* `prefer_const_declarations` updated to check locals
* fixes to `invariant_booleans`
* bumped SDK lower bound to `2.0.0-dev`
* build and workflow improvements: rule template fixes; formatting and header validation
* miscellaneous documentation fixes

* added fix
2 files changed
tree: f62aa06fb10c3bc0df267a630ac2044f458f03d4
  1. bin/
  2. doc/
  3. example/
  4. lib/
  5. test/
  6. tool/
  7. .gitignore
  8. .travis.yml
  9. analysis_options.yaml
  10. appveyor.yml
  11. AUTHORS
  12. CHANGELOG.md
  13. codereview.settings
  14. CONTRIBUTING.md
  15. LICENSE
  16. pubspec.yaml
  17. README.md
README.md

Linter for Dart

A Dart style linter.

Build Status Build status Coverage Status Pub

Installing

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

Usage

The linter gives you feedback to help you catch potential errors and keep your code in line with the published Dart Style Guide. Currently enforcable 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 annotate_overrides, hash_and_equals, and prefer_is_not_empty rules in the console. In practice you would probably configure quite a few more rules (the full list is here).

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'

tells the 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.

Contributing

Feedback is, of course, greatly appreciated and contributions are welcome! Please read the contribution guidelines; mechanics of writing lints are covered here.

Features and bugs

Please file feature requests and bugs at the issue tracker.