flutter-packages: a small index of Material Design packages for Flutter

Two packages live here, and the rest of the catalogue does not

The repository is described in one line as containing the source code for packages originally developed by the Flutter team at Material, and the README calls it a collection of useful Material Design packages.

The table at the top of the README lists exactly two. The first is dynamic_color, with links to its pub.dev page, to issues filtered by a per package label, to pull requests filtered the same way, and to a hosted example application. The second is dynamic_color_testing, which is listed with a pub.dev link but without the issue and pull request columns filled in.

That is the whole inventory, and it is smaller than the name suggests. A second table in the README lists other Material Design packages whose source code exists in other repositories: animations and google_fonts, both inside the flutter/packages repository, material_color_utilities, whose Dart implementation sits in material-foundation/material-color-utilities repository, and material_symbols_icons, which lives in a personal repository under a different maintainer entirely.

So the catalogue is split by accident of history rather than by policy, and a reader who arrives looking for Material Design in Flutter will find a small index and a map of where everything else went. That map is genuinely useful, because the alternative is searching pub.dev for each package and wondering who maintains it.

The project is Apache-2.0 licensed, the default branch is main, the last push was on 2026-10-01, and the publisher identity for the packages is material.io account on pub.dev, which the homepage field points at.

Per package labels replace per package issue trackers

The issue and pull request columns of the table are the most instructive part of the README, because they show how a monorepo handles the problem of one tracker serving several packages.

Each package gets a label, written as the package name with a p: prefix. The links in the table are pre-filtered views of the same repository's issues and pull requests, one per package, so a user reporting a bug in dynamic_color lands on a list that already contains only dynamic_color reports, and the same for any other package in the repository.

That is a small design decision with a real effect on triage. The alternative, a separate repository per package, multiplies the overhead of releases, labels and automation, and it is also the reason the packages in other repositories exist as they do. The label approach keeps one repository, one set of maintainer permissions and one contribution guide, and pays for it with a slightly awkward URL for each package's tracker.

The intake point is consistent with that. The README asks for bug reports and feature requests to be filed through the repository's issue chooser, which is the template mechanism that presents a form rather than a blank page, and a CODEOWNERS file at the root lets the project route a package to the people who look after it.

For a contributor, the README separates two cases. Changes to an existing package in this repository go through the contribution guide in the repository, while a brand new package for the Flutter ecosystem is a different process, with the documentation for developing packages and plugins linked from the README. The distinction is sensible, because adding a package to an existing publisher account is a different decision from proposing a new one to the ecosystem.

Publishing is a manual step by the publisher admins

The publishing section is three lines long, and it is the clearest statement of how a release happens in this project.

dart pub publish

It is run from the root directory of a package, and only by the admins of the publisher account at material.io on pub.dev. There is no mention of an automated release, a tag-driven publish or a continuous integration job that pushes to pub.dev, and the repository has no GitHub releases either, so the version history of these packages lives entirely on pub.dev.

That has consequences worth being explicit about. A user gets a new version of dynamic_color when a maintainer decides to publish one, not when a commit lands. The last push to the repository was on 2026-10-01, and the code may or may not have been published by the time you read this, so the gap between the source and the published artifact is something to check rather than assume.

For the maintainers, a manual publish has an upside that is easy to miss: it is a deliberate act with a human confirming the version bump and the changelog entry, on a package that thousands of applications depend on. The downside is that it does not scale, does not happen on a schedule and can be forgotten. The trade is the usual one between a personal publisher account that is fast to operate and a release pipeline that is reproducible.

The practical advice for a user is therefore simple. Treat pub.dev as the source of truth for versions, and treat the repository as the place where the code and the issues live.

The other Material packages are maintained somewhere else entirely

The second table deserves a closer look, because it maps the fragmentation of the whole Material Design set across four different homes.

animations and google_fonts sit in the flutter/packages repository, which is the general home for packages that the Flutter team maintains rather than the team at Material specifically. material_color_utilities has its Dart implementation in material-foundation/material-color-utilities repository, a separate project with its own issue tracker, which is where the colour maths behind Material Design palettes lives. material_symbols_icons, the icon set, is in a repository maintained by an individual contributor, with its own issue and pull request links, not under the organisation at all.

Each of those entries in the README table carries the same four links, pub, issues, pull requests, and for the ones in this repository a label, and each points at a different tracker. So a developer who needs an icon, a font package, an animation helper and a colour utility ends up with four different places to report problems, four different maintainer sets and four different release cadences, and the only thing tying them together is the README table.

That table is also a good argument for reading each package's own documentation rather than assuming a shared standard. The packages in this repository, the ones in the Flutter repository and the icon set maintained elsewhere are published by different accounts, with different version histories, and only the ones under material.io publisher are covered by the process described in the previous section.

The pattern is worth naming for anyone building a Material based Flutter app: the design system is a set of separately published packages, and the repository you are looking at now is one small corner of it.

Repository hygiene is configured, not documented

The repository root is small and shows a Flutter project set up the way the Dart community now expects.

There is an analysis_options.yaml, which is where the Dart analyzer configuration lives, so the lint rules the packages are checked against are in version control rather than in each developer's editor settings. There is a .pre-commit-config.yaml, which runs checks before a commit is created, and a .prettierignore, which keeps the formatter from touching files it should not.

The root also carries a pubspec.yaml and a pubspec.lock, which is how a Dart workspace with several packages is rooted, along with a .github/ directory for the workflows and issue templates, a .gitignore and a CONTRIBUTING.md.

The interesting pairing is the analysis options with the pre-commit configuration. In a Dart repository the analyzer only runs when somebody runs it, so the pre-commit hook is what turns the lint rules into something that actually happens, and the combination means a change that violates the analyzer configuration is caught before it reaches review rather than during it.

None of this is exotic, and that is the point. A repository that exists mainly to hold a few published packages can still get the mechanics of a well run project right, and here the mechanics are visible in the root listing rather than described in the README, which is itself a sign that the project is run by people who expect the configuration to speak for itself.

The README is an index, so the package documentation lives elsewhere

The limitation of this repository is a documentation one, and it is worth stating plainly before you adopt anything from it.

The README does not say what dynamic_color does. It does not list its API, its options, its platform support or its compatibility with Flutter versions, and the same is true of dynamic_color_testing. The only pointers to the actual behaviour are the pub.dev pages, the issue tracker, and the hosted example application linked from the table, which is material-foundation.github.io site for the dynamic_color example.

For a package, that is a reasonable division of labour, since pub.dev is where a Dart user looks first and where the API documentation is generated from the source. But it means the repository README cannot be used to evaluate the package, and it means the example application is the only place a newcomer can see the thing working.

So the practical checklist for a team considering these packages is short. Read the pub.dev page for the version you would actually resolve, run the example to see the behaviour in a real app, and file any question in the repository's issue tracker with the package label, since that is where the maintainers of these particular packages look.

One last detail about the catalogue as a whole. Because the packages are published by different accounts and maintained in different repositories, there is no single place that guarantees they move together, and the version constraints are resolved by pub.dev rather than by this repository. If you need a consistent set of Material packages in a large application, that consistency is something you have to arrange in your own dependency file.

Editorial conclusion

Adopt the packages in this repository if you are building a Flutter app and want Material's own implementations rather than a third party reimplementation, and if you want to file issues against the code that actually ships. Do not adopt the repository itself as a dependency, since it is a source tree of separate published packages rather than a library you import, and do not expect a single place to hold the whole Material catalogue, because most of it is maintained in other repositories. Before you depend on dynamic_color, read its page on pub.dev rather than the repository README, and check that the version you resolve is current, since publishing is a manual step by the publisher admins and the repository keeps no release tags of its own.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. material-foundation/flutter-packages on GitHub
4. Project website
5. README