runtime_lints

Description:

runtime lints

Runtime Lints #




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.

lints - from dart team
flutter_lints - from dart team
lint - community driven strict rules
import_lint
very_good_analysis
pedantic - DEPRECATED

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 #

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
copied to clipboard

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
copied to clipboard
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.

⚠️ 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 {}
copied to clipboard
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 {}
copied to clipboard
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
copied to clipboard
Badge #
To indicate your project is using runtime_lints →

[](https://pub.dev/packages/runtime_lints)
copied to clipboard