dart-lang/samples: runnable Dart examples for the features you keep forgetting

What the collection is, and who maintains it

The repository describes itself as a collection of Dart programs that illustrate features and best practices, and it is maintained by Dart DevRel. That is the whole scope, and the scope is the point. A samples repository is not a framework and not a package you depend on, it is a set of examples that someone has verified runs, with the reasoning visible in the code. The README also points readers to Awesome Dart for a list of community-maintained projects, which tells you the division of labour: this repository covers the language and the platform, and the community list covers everything built on top of it. The primary language is Dart, the licence is BSD-3-Clause, the default branch is main, there are no GitHub releases, and the last push was on 2026-09-01. The README also links the Dart tutorials and a contributing guide for adding to the collection.

The index, sample by sample

The index in the README is short enough to read in full, and each entry says what the example is for. The command_line sample is a command line app that parses command line options and fetches from GitHub. The extension_methods set demonstrates the extension methods syntax and shows some common use cases of the feature. The null_safety/calculate_lix sample calculates the lix readability index with an implementation that uses the Dart null safety feature. The ffi series gives simple examples of calling C libraries from Dart. The isolates samples are command line applications demonstrating concurrency with isolates, where the examples read and parse JSON content in a worker isolate and return the result to the main isolate. The native_app sample is a command line application that can be compiled to native code using dart compile exe. The server directory holds examples of running Dart on the server, and package_constraint_solver demonstrates best practices for publishing packages on pub.dev. The README also lists a separate project, Pop, Pop, Win!, an implementation of Minesweeper in Dart by the Dart team, in its own repository.

The repository tree reveals samples the index does not list

The top level directory listing is wider than the README index, and that difference is informative. Alongside the directories the index mentions, the tree contains enhanced_enums/ and parameters/, which are not in the published list. That tells you the repository is a working document: samples get added as features land, and the index is updated on a slower cadence than the tree. It also means the set of examples is not fixed, so anyone planning to use it as a checklist should look at the tree rather than trust the index alone. The tool/ directory and the mono_repo.yaml file at the root are the infrastructure. A mono_repo.yaml file is configuration for repository-wide tooling, which is how a collection of independent sample directories stays consistent.

Where each sample earns its place, and what it costs to read

The collection is organised by problem rather than by library, and that is what makes it useful. Someone who has just learned about isolates can go to the isolates directory and see a worker parsing JSON and handing the result back, which is a different thing from reading the concurrency documentation. Someone working on a native executable can look at native_app and see what dart compile exe expects. Someone preparing to publish can look at package_constraint_solver for the conventions around publishing. The cost of this approach is that the examples are snapshots. They were written against a particular SDK and a particular set of package versions, and the repository publishes no releases and is not versioned as a package, so there is no upgrade path that tells you when an example has been refreshed against a new SDK. The examples in the tree that are not in the index are the visible symptom of that, and a reader who copies a fragment without opening the sample's own README and pubspec is working from code of unknown vintage.

The limits, and the alternative to weigh

Three boundaries are worth naming. The first is scope. These are language and platform samples, not application architecture, so there is no example here of how to structure a production service, and the server directory is explicitly examples of running Dart on the server rather than a framework opinion. The second is the fact that the collection reflects the language at the moment each sample was written, so features that have moved on, and patterns the team has since changed its mind about, are still present. The third is that a sample teaches the feature, not the ecosystem: a working FFI example is not a working binding generator, and a working isolate example is not a job queue. The alternative to weigh is the official documentation and the API reference, which are versioned with the SDK and state the current guidance. The difference in approach is that the samples show you one correct way to do something in enough context to run it, while the documentation tells you what the current contract is. For learning a feature well enough to write it yourself, the samples win. For knowing what to do today, the documentation wins. Most people need both, in that order.

Editorial conclusion

Adopt this repository as a lookup table rather than as a dependency, because its value is that each example is a small program you can run and read end to end rather than a fragment. Do not expect it to cover the modern library surface, because several of the samples are tied to specific feature eras, and check the state of the example before you copy from it. Before you rely on a sample in production, open its own README and pubspec, look at the Dart SDK constraint in there, and confirm the API it uses still exists in the SDK you ship against, since the repository itself publishes no releases and is not versioned as a package.

Frequently asked questions

Official sources

1. dart-lang/samples on GitHub
2. Issues
3. License: BSD-3-Clause
4. README