FlutterTrends: Daily Flutter Package Rankings Backed by Real pub.dev Data

Choosing a Flutter package usually means opening six tabs: pub.dev for pub points, GitHub for last commit date, a license check, maybe a star count — and then deciding anyway. FlutterTrends.dev tries to collapse that into one page by ranking packages strictly on data pub.dev and GitHub already publish. No editorial picks, no invented quality scores. As of its last run on October 17, 2026, it tracked 32,155 packages and 28,758 GitHub repositories.

Three leaderboards, three signals

FlutterTrends maintains three separate rankings, each answering a different question:

• Most downloaded ranks by daily downloads — pub.dev’s 30-day total divided by 30. The site is explicit that this is a 30-day average, not yesterday’s true count, because a rolling total can’t recover the real daily number. Dividing every package by the same constant preserves the order, so the ranking is identical to the raw 30-day total.
• Most active ranks by total commits to the linked GitHub repository over the past 52 weeks. This surfaces packages that are being built, not just downloaded — useful for spotting widely used but stalled dependencies.
• Movers ranks by day-over-day change in the downloads leaderboard, which is how you find a package climbing before it’s ubiquitous.

Underneath the leaderboards sit per-category pages — State Management (1,440 packages), HTTP & Networking (2,549), UI Components (8,390), Navigation & Routing (480), Firebase (635), Push Notifications (275), and dozens more.

How the data pipeline works

Every day at 03:00 UTC, FlutterTrends snapshots pub.dev’s top 20,000 packages. If a package is below that bar, it isn’t on the site — that’s the answer to “why is package X missing?”. Once a week, GitHub data refreshes for any package whose code lives there. The site itself rebuilds nightly off the fresh data, and everything derived — day-over-day rank movement, weekly commit activity, monorepo context, license summaries — comes from those two sources.

Category assignment is three-tiered. First, the topics the package author set on pub.dev. If none are set, a keyword match on name and description. For packages still uncategorized, an AI model reads the description and picks 0–3 categories from the site’s taxonomy — but only fills gaps the rule-based pass missed; it never overrides a rule match.

The repository-health panel is the real value

Ranking by downloads is pub.dev’s job already. The part you can’t get in one place elsewhere is the health panel, which surfaces for any package with a GitHub repo:

• last commit date and archived status
• open issues and pull requests
• contributor count and bus-factor share
• CI presence and the license file detected on the repo
• a 52-week commit-activity sparkline with derived stats on click
• a plain-English summary of what the detected license permits and requires

There’s a nice touch for monorepos: the site says roughly 30–40% of the most-used Flutter packages are subpackages of a larger repo (dart-lang/sdk backs analyzer, meta, vm_service, and more). When several tracked packages share a repo, the health panel labels itself “shared with N sibling packages” — so a pile of open issues reads as shared-infrastructure context, not a per-package alarm.

Flags, sponsors, and what the site won’t do

Each verified publisher maps to one country code, rendered as a flag on leaderboard rows. Three self-disclosed signals decide it: the publisher’s domain suffix, its GitHub owner profile location, and the contact email on the pub.dev publisher page. First clear signal wins; publishers with no clear signal render no flag rather than a guess.

On incentives: FlutterTrends was built by Sebastian Szczygiel, co-founder of Primio, an AI app builder that needed an answer to “which packages should the AI actually pick?” — LLMs limited by training-data cutoffs will happily recommend abandoned libraries. Primio sponsors the site, and the banner on every page is a paid placement, always labeled. The rankings themselves are not for sale; they run on pub.dev and GitHub data alone, with no affiliate links.

Using maintenance signals in your own project

Whether you use FlutterTrends or check GitHub yourself, the practical move is making staleness a build-time signal instead of a quarterly surprise. A small CI script that fails on archived or long-dormant dependencies turns the health panel’s questions into gates:

# .github/workflows/deps.yml — flag dependencies whose repos went quiet
name: dependency-health
on:
  schedule:
    - cron: '0 6 * * 1' # weekly, after FlutterTrends' Monday refresh
  workflow_dispatch:

jobs:
  health:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dart-lang/setup-dart@v1
      - name: Check hosted dependency freshness
        run: dart run tool/dep_health.dart

Pair it with a dependency_overrides escape hatch so a flagged package doesn’t hard-block a release:

# Try a maintained community fork while you migrate.
dependency_overrides:
  some_abandoned_package:
    git:
      url: https://github.com/some-org/some-abandoned-package-fork.git

That pattern — flag the stale dependency, override to a maintained fork, migrate deliberately — is exactly the workflow the site was built to support.

What FlutterTrends is not

It’s not a “best of” list. The About page is blunt: the repository-health panel reports facts from GitHub, not letter grades. Day-over-day trend charts for established packages look flat by design, because each point includes 29 days of overlapping history with the next — the chart only comes alive over weeks. Read the data and decide for yourself; that’s the whole pitch.

If you maintain a package in pub.dev’s top 20k that’s miscategorized or missing, the site publishes a contact address and asks to be told. It’s a refreshingly literal interpretation of “ranked by real data” — and in an ecosystem where AI agents now pick dependencies as often as humans do, ranked-by-downloads-with-a-health-panel is a better default than training-data memory.

Sources

• FlutterTrends.dev
• About FlutterTrends — methodology FAQ