Runtime Lints

pub package License: MIT style: very good analysis

This package provides lint + static analysis rules for Dart and Flutter which are used internally on all open-runtime repositories which power the Runtime.Dev platform.

Inspiration

There are a lot of community driven efforts to create a recommended set of linting rules. Their work inspired this repository.

Exploring Linting + Analysis Rules

To learn more about Flutter/Dart linting and understanding what the individual rules mean and why they exist, check out the official Dart documentation.

You can also look at the Github Pages hosted version of these linter rules which offer better experience by pairing easy-to-understand good/bad example snippets that showcase the rules and their usage.

Usage

  1. To use the lints, add a dependency in your pubspec.yaml. Use the Runtime Lints as a dev dependency to prevent users of your library from being forced to download runtime_lints:
dev_dependencies:
  runtime_lints: ^0.3.0
  1. Set the include: in your project's analysis_options.yaml. This will ensure you always use the latest version of the linters and analysis rules:
include: package:runtime_lints/recommended.yaml

Suppressing Lints

There may be cases where specific lint rules are undesirable. Lint rules can be suppressed at the line, file, or project level.

An example use case for suppressing lint rules at the file level is suppressing the prefer_const_constructors in order to achieve 100% code coverage. This is due to the fact that const constructors are executed before the tests are run, resulting in no coverage collection.

:warning: A Word of Caution: Linter rules are designed to keep consistent style and prevent developers from making easy-to-identify mistakes. While it is not uncommon to make linting rules restrictive to over-communicate to developers about potential risks, this can get out of hand quickly. CI/CD could be used to enforce linting guidelines (i.e. with a dart analyze command), but if this is set up as a merge condition for your repository, you may find that you would suppress otherwise useful rules just to "pass the merge checks". This can cause repositories to devolve into a spaghetti code mess of ignore rules that you see below.

It's important to weigh the options of selecting linter rules for your organization/team and deciding how to enforce them.

Line Level

To suppress a specific lint rule for a specific line of code, use an ignore comment directly above the line:

// ignore: public_member_api_docs
class A {}

File Level

To suppress a specific lint rule of a specific file, use an ignore_for_file comment at the top of the file:

// ignore_for_file: public_member_api_docs

class A {}

class B {}

Project Level

To suppress a specific lint rule for an entire project, modify analysis_options.yaml:

include: package:runtime_lints/recommended.yaml
linter:
  rules:
    public_member_api_docs: false

Badge

To indicate your project is using runtime_lints → style: runtime lints

[![style: runtime lints](https://img.shields.io/badge/style-runtime_lints-B22C89.svg)](https://pub.dev/packages/runtime_lints)

Libraries