Developed by Saropa. Making the world of Dart & Flutter better, one lint at a time.
Flutter's ecosystem is young. The mature tooling that other platforms take for granted — security analysis, accessibility enforcement, architectural guardrails — is still catching up.
Good options exist, but many are paid or closed-source. We believe these fundamentals should be free and open. A rising tide lifts all boats.
Dart's analyzer catches syntax errors. saropa_lints catches the rest:
- Security — Hardcoded credentials, unsafe deserialization, input validation gaps
- Accessibility — Missing semantics, inadequate touch targets, screen reader issues
- Performance — Unnecessary rebuilds, memory leaks, expensive operations in build methods
- Maintainability — Inconsistent patterns, error handling gaps, architectural drift
The tier system lets you adopt gradually. Start with 50 critical rules, work up to 1000 when you're ready.
# pubspec.yaml
dev_dependencies:
custom_lint: ^0.8.0
saropa_lints: ^1.1.12# analysis_options.yaml
analyzer:
plugins:
- custom_lint# analysis_options.yaml
custom_lint:
saropa_lints:
tier: recommended # essential | recommended | professional | comprehensive | insanitydart run custom_lintPick the tier that matches your team:
| Tier | Rules | Best For |
|---|---|---|
| Essential | ~100 | Every project. Prevents crashes, memory leaks, security holes. |
| Recommended | ~300 | Most teams. Adds performance, accessibility, testing basics. |
| Professional | ~600 | Enterprise. Adds architecture, documentation, comprehensive testing. |
| Comprehensive | ~800 | Quality obsessed. Best practices everywhere. |
| Insanity | 1000 | Greenfield projects. Every single rule. |
# analysis_options.yaml
custom_lint:
saropa_lints:
tier: recommended # Most teams start hereAvailable tiers: essential, recommended, professional, comprehensive, insanity
After choosing a tier, you can enable or disable specific rules:
custom_lint:
saropa_lints:
tier: recommended
rules:
# Disable a rule from the tier
avoid_hardcoded_strings_in_ui: false
# Enable a rule from a higher tier
require_public_api_documentation: true| Category | Description |
|---|---|
| Flutter Widgets | Lifecycle, setState, keys, performance |
| State Management | Provider, Riverpod, Bloc patterns |
| Performance | Build optimization, memory, caching |
| Security | Credentials, encryption, input validation |
| Accessibility | Screen readers, touch targets, semantics |
| Testing | Assertions, mocking, flaky test prevention |
| Architecture | Clean architecture, DI, SOLID principles |
| Error Handling | Exceptions, logging, recovery |
| Async | Futures, Streams, cancellation |
| API & Network | Timeouts, retries, caching |
| Internationalization | Localization, RTL, plurals |
| Documentation | Public API, examples, deprecation |
Running all 1000 rules uses significant memory. The tier system helps:
- Rules set to
falseare not loaded - Start with
essentialorrecommended - Upgrade tiers as you fix warnings
# GOOD: Start with recommended tier
custom_lint:
saropa_lints:
tier: recommended
# BAD: Enabling everything at once on a legacy codebase
custom_lint:
saropa_lints:
tier: insanity # May show thousands of warningsStart with professional or comprehensive. Fix issues as you write code.
- Enable
essential. Fix critical issues first. - Move to
recommended. Fix warnings as you touch files. - Enable higher tiers when the noise is manageable.
When a rule doesn't apply to specific code:
// ignore: avoid_hardcoded_strings_in_ui
const debugText = 'DEBUG MODE';
// For entire files:
// ignore_for_file: avoid_print_in_productionAlways add a comment explaining why you're suppressing.
Works automatically in:
- VS Code with Dart extension
- Android Studio / IntelliJ with Dart plugin
- Command line via
dart run custom_lint
Issues appear as you type with quick-fix suggestions.
We believe great tools are built by communities, not companies. Contributions and feedback are always welcome.
If you think a rule is:
- Wrong - tell us why, we'll fix it or remove it
- Too strict - maybe it belongs in a higher tier
- Too lenient - maybe it should be stricter or have options
- Missing - propose it, or better yet, implement it
We don't have all the answers. If you've shipped production Flutter apps and have opinions, we want to hear them.
See CONTRIBUTING.md for detailed guidelines.
Adding a new rule:
- Create rule in appropriate
lib/src/rules/*.dartfile - Add to the appropriate tier(s) in
lib/tiers/*.yaml - Add tests in
test/rules/*_test.dart - Update CHANGELOG.md
Reporting issues:
- Include a minimal code sample that triggers (or should trigger) the rule
- Explain what you expected vs what happened
- If you disagree with a rule's premise, say so directly
Not sure if something is a bug or a design decision? Open a discussion issue. We're happy to explain our reasoning and change our minds when presented with good arguments.
Optional paid services for teams that want hands-on help. See ENTERPRISE.md for details.
| Service | Description |
|---|---|
| Codebase Assessment | We analyze your codebase, prioritize findings, create a remediation roadmap |
| Remediation | We fix the issues — you stay focused on features |
| Custom Rules | Rules specific to your architecture and compliance requirements |
| Training | Team workshops on Flutter best practices |
Contact: saropa.com | lints@saropa.com
To indicate your project is using saropa_lints:
[](https://pub.dev/packages/saropa_lints)MIT - see LICENSE. Use it however you like.
Built with care by the Flutter community. Questions? Ideas? We'd love to hear from you.