sentry-dart: one repository, eight pub.dev packages, one major release in October

A monorepo where each integration is its own pub.dev package

getsentry/sentry-dart is the Sentry SDK for Dart and Flutter, written in Dart and published under the MIT licence. What makes it interesting is not the SDK itself but how it is cut up.

The repository publishes separate packages rather than one. The list in the README runs from the base sentry package through sentry_flutter, sentry_logging, sentry_dio, sentry_link, sentry_file, sentry_sqflite and sentry_drift, and the table is cut off at the end, so there may be more. Each one is published on pub.dev and each has its own CI workflow in the repository: dart.yml for the base package, flutter.yml for the Flutter integration, and separate logging, dio, link, file, sqflite and drift workflows for the rest. The package table also links out to pub.dev for the likes, downloads and analysis scores of each package, so the ecosystem feedback is per package rather than for the repository as a whole.

The consequence for a user is that you choose how much of the SDK you take. A pure Dart command line tool needs the base package. A Flutter application adds the Flutter integration. An app that talks HTTP through the dio client adds that package too.

Each package page is where the details live:

https://pub.dev/packages/sentry
https://pub.dev/packages/sentry_flutter
https://pub.dev/packages/sentry_logging
https://pub.dev/packages/sentry_dio
https://pub.dev/packages/sentry_link
https://pub.dev/packages/sentry_file
https://pub.dev/packages/sentry_sqflite
https://pub.dev/packages/sentry_drift

The repository layout matches: a packages/ directory holds the sources, with the repository-level pubspec.yaml and melos.yaml at the root, the way a Dart monorepo with many published packages is usually arranged.

Package names tell you the integration surface

The README does not describe what each package does in prose. It gives you a table of packages, badges and links, and then stops, so the only guide to scope is the package naming and the documentation site listed as the homepage, which points at the Sentry documentation for Dart and Flutter.

Reading the names tells you a lot about the split. The base sentry package is the core SDK and is the one that would carry the transport, the event pipeline and the configuration. sentry_flutter is the Flutter layer, and its CI workflow is separate from the Dart one, which tells you it has its own toolchain and its own test matrix. sentry_logging sits between the SDK and the logging ecosystem. sentry_dio is named after the dio HTTP client, so it is the integration that captures HTTP traffic from that client, and the fact that it has its own workflow suggests the integration carries its own tests rather than piggybacking on the core package. sentry_link concerns links, sentry_file concerns file operations, and sentry_sqflite and sentry_drift are the two database integrations, one for the sqflite plugin and one for the drift ORM.

That last pair is the clearest example of the design principle. Two different ways of talking to SQLite in the Dart world, and the SDK covers both, each behind its own package and its own CI workflow. The cost of that approach is dependency count, and the benefit is that a project only compiles the integration it actually uses.

If you need the exact API of a given package, the repository does not summarise it, and the pub.dev page or the Sentry documentation for Dart and Flutter is the place to look.

Version 10.0.0 and its release candidate landed days apart

The release history in the repository is short and recent. Version 10.0.0-rc.2 was published on 2026-10-02, 10.0.0 on 2026-10-09, and 10.1.0 on 2026-10-15. The last push was on 2026-10-22, so the repository was being worked on days after the newest tag.

A major version bump is a signal in any SDK, and here it comes with a release candidate that precedes it by a week, which is the normal pattern for letting users test a breaking change before it lands. What is unusual is the gap between 10.0.0 and 10.1.0, six days, which suggests an early patch release on a fresh major version.

For an adopter the practical instruction is simple and unglamorous: read CHANGELOG.md at the root of the repository before you upgrade, and read it for the specific package you depend on rather than for the repository in general, since the packages version independently under their own workflows. The topics list includes hacktoberfest, which means the repository takes contributions from outside, and that raises the chance of behavioural changes reaching a minor version faster than you would expect from a mature SDK.

The MIT licence keeps the terms simple for both commercial and open-source use, and how a hosted error-reporting service fits into your own data policy is a question for your own review rather than for this article.

The repository carries its own test and release scaffolding

The top level of the repository is worth reading as a map of the practices behind the packages. Alongside the source and documentation sit a set of directories and files that most SDK repositories do not have.

There is an e2e_test/ directory for end-to-end tests and a min_version_test/ directory, which is a separate test suite for the oldest versions the SDK still supports. That second directory is the one to look at before choosing a version, because it encodes the supported floor of Dart and Flutter in executable form rather than in prose. A .fvmrc file at the root pins the Flutter version used for development, which is how a multi-package repository keeps its toolchain consistent.

Then there is the release and quality tooling. The .github/ directory holds the per-package workflows named in the package table, a codecov.yml configures coverage reporting, and a metrics/ directory suggests the project tracks its own numbers. A scripts/ directory holds the automation, and .githooks/ holds the git hooks that keep commits and branches consistent.

The AI-agent configuration files are also visible: .agents/, .claude/, .cursor/, agents.toml, AGENTS.md and CLAUDE.md. That is a signal about how the project expects contributions to be made, and it costs nothing to read those files before opening a pull request.

What the README does not tell you

The documentation here is thin, and the gap matters for a first-time user.

There is no installation snippet, no initialization example and no configuration sample in the README. The setup steps for the SDK are not written down there, and the repository's homepage is the Sentry documentation site for Dart and Flutter, so the configuration reference lives outside the repository. If you are evaluating the SDK, you will have to read the hosted documentation, and the README gives you no summary of what the options are or which are required.

The privacy angle is not addressed either. The topics list mentions tag-production and team-mobile, and the repository is a mobile-oriented SDK, but the README does not describe what data leaves the device, how it is filtered before sending, or how to sample events. Those are exactly the questions a team should answer before turning on crash reporting in an app that handles user data, and the answer is not in this repository.

Two other silences are worth noting. There is no mention of a supported Dart or Flutter version range in the README, only the min_version_test directory that implies one, and there is no migration guide for a 9.x to 10.x upgrade beyond the changelog. Plan for a short discovery phase, where you read the hosted documentation and the changelog side by side, and where you verify the version floor in the repository rather than from a blog post.

The base package instead of the whole SDK

The real decision inside this repository is not which SDK to use but how many of its packages to take, and the alternative to taking them all is the base package.

A pure Dart backend or command line service that only wants to report exceptions can depend on sentry alone. That avoids the Flutter dependency entirely, which matters for a service that runs in a container where the Flutter SDK is not installed and has no business being. Adding sentry_flutter to such a project buys nothing, because the Flutter-specific code paths are never executed there.

The difference in approach is that the monorepo splits by integration rather than shipping one package with optional features. An optional feature inside a single package is invisible in your dependency graph and hard to disable, whereas a separate package is a separate entry in pubspec.yaml, and a reviewer can see at a glance that the app depends on the Flutter integration and the dio integration and nothing else. The cost is that each additional package is another version constraint to track, and given that 10.0.0 and 10.1.0 landed a week apart, that cost is real: you will be pinning versions of several packages that move independently.

The other alternative is to skip the SDK entirely and post events to the Sentry ingestion endpoint yourself over HTTP. That gives full control over what is sent and when, and it removes the SDK from your build. What it gives up is the entire reason this repository exists, which is the set of integrations that know what a Flutter widget tree, a dio request or a drift query looks like. For a plain Dart service with no framework, that hand-written client is a reasonable trade. For a Flutter app, the per-integration packages are the point.

Editorial conclusion

Adopt the sentry package plus the one integration package your stack needs, such as sentry_flutter, sentry_dio or sentry_drift, rather than pulling the whole monorepo into a build, because each package has its own CI workflow and its own release. Do not start an integration on 10.0.x without reading CHANGELOG.md, since that major version landed on 2026-10-09 and 10.1.0 followed on 2026-10-15, which is a fast sequence for a breaking release. Before you wire it up, confirm the Dart and Flutter versions your app targets against the min_version_test directory, and set up the crash reporting initialisation in one place, since the repository ships no setup snippet and the configuration reference lives in the Sentry documentation for Dart and Flutter.

Frequently asked questions

Official sources

1. getsentry/sentry-dart on GitHub
2. License: MIT
3. Project website
4. README
5. Releases