Differentiator

Custom Flutter Lint Package

Architecture rules fail the pull request. Consistency does not depend on one person.

Clay illustration of a custom lint package
Custom Flutter Lint Package featured graphic

How it works

A left-to-right map of the work. Ports stay on fixed sides so the edges do not cross more than they have to. Pan or pinch if you want a closer look.

warning • architecture • lib/features/orders/page.dart:41

avoid_presentation_importing_data

Presentation must talk to domain, not data sources.

Internal lint · redacted example

The usual problem

  • Presentation imports data because “just this once”.
  • A lead’s review is the only architecture check, so quality drops when they are busy.
  • Documentation is a wiki that nobody updates.

How I approach it

  • Rules come from the production codebase, not from a generic linter preset.
  • Architecture boundaries, coding standards, and documentation gates all run in CI.
  • The same package is heading toward an open-source release.

Process

  1. 01

    Extract

    Rules taken from real production failures, not from a blog list.

  2. 02

    Package

    An internal Flutter lint package the whole org can depend on.

  3. 03

    Enforce

    CI runs it on every PR.

  4. 04

    Share

    In progress toward an open-source release.

Stack and tools

Custom Flutter lintArchitecture rulesDocumentation gatesCI on every PR

Proof from real work

Kadipay and MDBriefcase

Author and maintainer

The internal lint package is used on both products and enforced in review.

Open the case study

What you get

  • The lint package
  • The rule list and what each rule is for
  • CI wiring so a PR cannot skip it

How risk stays down

  • Consistency does not depend on one reviewer being online.
  • Architecture violations fail the build, not a later cleanup ticket.

Questions agencies ask