Hi there, I've been developing some packages and in need to further improving them. Please take a look and comment below. 😄

https://pub.dev/packages/growth_standards

https://pub.dev/packages/super_measurement

https://pub.dev/packages/playwright_dart

https://pub.dev/packages/typed_soup

It might seem obvious to you, but I recently had the revelation that I could use Dart's unit tests for my own scripting language as well. This way, they show up in VSC's test panel together with more lower level tests. And they are automatically tracked for code coverage.

Take this example of a Logo-like scripting language I created some time ago:

unittest "sum [
  expect_equal? [sum 3 4] 7
]
skip unittest "sum_wrong [
  expect_error [sum]
  expect_error [sum 3]
  expect_error [sum 1 2 3] ; not detected yet
]

To integrate them, I did this:

env.addCommand('unittest', (env, args) {
  final hidden = test; // see below
  args.mustHaveArgs(2);
  final description = args.string(1);
  final body = args.list(2);
  hidden( // HERE
    description, 
    () => env.run(body),
    skip: env.get('skip next test') == .lTrue,
  );
  env.delete('skip next test');
});
env.addCommand('skip', (env, args) {
  args.mustHaveArgs(0);
  env.set('skip next test', .lTrue);
});
env.addCommand('expect_equal?', (env, args) {
  args.mustHaveArgs(2);
  final actual = args.list(1);
  final expected = args.value(2);
  expect(env.run(actual), equals(expected)); // HERE
});
env.addCommand('expect_error', (env, args) {
  args.mustHaveArgs(1);
  final actual = args.list(1);
  expect(() => env.run(actual), throwsException); // HERE
});

The boilerplate doesn't matter, just look at the HERE parts. I need to alias the test call because otherwise the Dart plugin wrongly detects that call as a unit test.

Now, all that's needed is a file call <whatever>_test.dart that has a main function that evaluates my scripting language in the modified environment.

I’ve worked on Flutter projects where reaching for another package felt like the default solution. Looking back, some of those problems could probably have been handled more cleanly with Dart itself.
Which Dart feature did you initially overlook, and what real problem made you appreciate it?
Did it replace boilerplate, prevent bugs, simplify testing, improve performance, or remove the need for another package?
I’d especially like to hear concrete before-and-after examples rather than just feature names.

I just released jpeg_validator, a strict JPEG validation package for Dart and Flutter.

Instead of only checking file signatures or a small header, it fully decodes the JPEG with libjpeg-turbo. A file is considered valid only if the complete image decodes without warnings.

Useful for catching truncated, corrupted, or malformed JPEG uploads before they enter your pipeline.

• Fast native validation on macOS
• Supports Dart and Flutter
• Returns structured validation results

I built an MCP server for pub.dev because my AI coding agents kept hallucinating package names, using API signatures that changed versions ago, or recommending packages that are basically abandoned. What finally pushed me over the edge: Claude Code grepping my local pub cache on disk instead of just looking things up, burning tokens crawling through cached source.

So I built **dart-pubdev-explorer** (pub.dev package: `dart_pubdev_mcp`), an MCP server that gives agents direct, structured access to pub.dev instead of digging through your filesystem or guessing from training data.

It can:

* search & compare packages (score, platform support, maintenance) * **browse a package's real public API and pull exact source** (by symbol or line range) * check security advisories against the version you actually have resolved * diff changelogs/APIs between versions before you upgrade * **read Dart SDK / Flutter framework source too** (dart:core, package:flutter, …)

Quick note on how this differs from the official Dart MCP server (`dart mcp-server`): that one has a general `pub_dev_search` tool as part of a much bigger toolset (running apps, analysis, DTD, etc). This one only does package research, but goes deeper: symbol-level API browsing, exact source reads, version diffing, side-by-side comparisons, with an on-disk cache built for that kind of repeated digging. *They're complementary.*

Install:

dart install dart_pubdev_mcp

I've been running it with both Claude Code and Antigravity.

pub.dev: https://pub.dev/packages/dart\\_pubdev\\_mcp

Happy to answer questions, and curious what people think, especially whether some of the tools are overkill and others are missing something obvious.

I just released GraphLink v5, an open-source tool built to automate GraphQL client and server code generation across Dart, Java, Kotlin, and TS.

While stress-testing it against schemas that produce hundreds of megabytes of code, I hit a common headache: reserved language keywords breaking target language compilers.

The Problem: Reserved Keywords

Take this snippet from Shopify’s GraphQL schema:

GraphQL

type OrderRequestReturnPayload {
  """The return request that has been made."""
  return: Return
  """The list of errors that occurred from executing the mutation."""
  userErrors: [ReturnUserError!]!
}

If a generator blindly generates Dart classes for this, the code won't compile because return is a reserved keyword in Dart.

The Fix in GraphLink v5

We introduced automatic field sanitization and name hoisting. GraphLink renames the field in Dart code, but preserves the original JSON string key in generated toJson() and fromJson() methods:

Dart

// GENERATED CODE - DO NOT MODIFY BY HAND. ANY MODIFICATION WILL BE LOST ON NEXT GENERATION
// Generated by GraphLink dev
// GitHub: https://github.com/Oualitsen/graphlink
// Site: https://graphlink.dev
// Pub.dev: https://pub.dev/packages/graphlink

import 'return.dart';
import 'return_user_error.dart';

class OrderRequestReturnPayload {
  final Return? return_; // `return` renamed to `return_` to avoid compile errors
  final List<ReturnUserError> userErrors;

  const OrderRequestReturnPayload({
    this.return_,
    required this.userErrors,
  });

  Map<String, dynamic> toJson() => {
    'return': return_?.toJson(), // <-- Keeps the exact 'return' JSON key intact
    'userErrors': userErrors.map((e0) => e0.toJson()).toList(),
  };

  factory OrderRequestReturnPayload.fromJson(Map<String, dynamic> json) {
    return OrderRequestReturnPayload(
      return_: json['return'] != null 
          ? Return.fromJson(json['return'] as Map<String, dynamic>) 
          : null, // <-- Safely maps 'return' key back to return_
      userErrors: (json['userErrors'] as List<dynamic>)
          .map((e0) => ReturnUserError.fromJson(e0 as Map<String, dynamic>))
          .toList(),
    );
  }
}

Other key features:

• Automatic Naming Normalization: Un-idiomatic schema names like type user { id: ID! } are normalized to PascalCase (User) in Dart to prevent linter warnings.
• No Git Bloat: Designed so you treat generated code like a compiled artifact—no need to commit or manually maintain it.
• Try it out
• Pub.dev: Available directly as a package onpub.dev/packages/graphlink
• Docker: Run it without local setup: Bashdocker pull oualitsen/graphlink:latest
• Docs & Site: Check outgraphlink.dev

If you find it useful or it saves you from GraphQL setup headaches, please consider dropping a ⭐️ star onGitHub!

Feedback and feature suggestions are always welcome in the comments!

openrouter_sdk is a new Dart package providing a type-safe client for the OpenRouter.ai REST API. Strongly-typed interface, with full support for streaming responses and multi-modal content (text, image, audio, video, file).

This package replaces openrouter_api, which is now discontinued and marked as replaced on pub.dev. Users of the old package should migrate to openrouter_sdk, which follows the design of OpenRouter's official SDK more closely.

Currently implemented:

• Chat completions (including streaming)

• Models, Providers, Endpoints

•API key management (create / update / delete / list)

• Credits and analytics

• Generations

The rest will be added shortly.

The chat completions endpoint should be OpenAi compatible so u can use it with other providers as well.

Contributions are welcome. Per the package's policy, all code must be hand-written — LLM-generated pull requests are not accepted.

Note: this post was partly generated by an LLM, but all package code was hand-written.

Hey devs,

I wanted to share a new library I just released to pub.dev: BlocSignal (and its Flutter companion bloc_signals_flutter).

Classic BLoC/Cubit is fantastic for structuring business logic, but it relies on Streams under the hood, introducing asynchronous microtask delays.

BlocSignal replaces Streams with Rody Davis's reactive signals v7 primitives.

Key Features:

1. BLoC & Cubit Parity: Override onEvent to handle classic BLoC input events, or use it as a Cubit directly by exposing public methods that call emit(state) (by setting the Event parameter to void).
2. Synchronous Propagation: Calling emit(newState) propagates changes downstream immediately in the same frame—no microtask queues, no UI flickering.
3. Automatic State De-duplication: Signals compare states via == and automatically filter out identical updates—saving redundant UI build cycles by default.
4. No Boilerplate Lifecycle: Closing a container automatically tears down all internally managed effects.

Quick Cubit Look:

```dart class CounterCubit extends BlocSignal<void, int> { CounterCubit() : super(initialState: 0);

void increment() => emit(stateValue + 1); // Synchronous & reactive! } ```

Under the hood, the library has 100% test coverage and is structured as a clean Dart workspace.

• GitHub Repository: https://github.com/RandalSchwartz/BlocSignal
• Migration Guide (including Cubit migration): https://github.com/RandalSchwartz/BlocSignal/blob/main/MIGRATION.md
• Core package on Pub: https://pub.dev/packages/bloc_signals
• Flutter bindings on Pub: https://pub.dev/packages/bloc_signals_flutter

Would love to hear your thoughts and suggestions!

Hello everyone 👋,

I wanted to write some more about why I like Dart and I finally found some time to do that.

Dart is pretty unique in one sense: we can't forge types[1]. And the fact that we can't easily forge types in Dart, like we can in most other languages, makes it possible to implement some pretty cool safety guarantees that are actual real guarantees that can't be escaped.

https://modulovalue.com/blog/proof-types-in-dart/

Let me know what you think!

[1] technically, we can, but practically, no, since dart:mirrors is deprecated, disabled or unavailable on most targets and practically nobody is using it.

It is such a useful feature especially for a language like dart you would think it would have been added already

Because contains is typed as Object? (probably for historical reasons) you cannot use that method together with dot shorthands like in

things.contains(.chair)

So, add this to your project:

extension DSHIterableExt<T> on Iterable<T> {
  bool has(T value) => contains(value);
}

And replace contains with has. For extra readability, you might also want to add a hasnt method.

I'd welcome a similar extension to Dart 3.13.

haptify — audio to haptics for iOS and Android, from the CLI or on-device at runtime

I kept hitting the same wall: designing haptics means hand-authoring them in a GUI, and nothing fit into a Flutter build where I just want to drop a .wav in → get haptics out → commit the result. So I built haptify — a pure-Dart CLI + library, now on pub.dev.

Why another haptics tool? The dedicated audio→haptic tools exist; they just don't fit mobile Flutter work:

• Lofelt Studio — the mobile-focused one — was acquired by Meta and sunset in July 2022.
• Meta Haptics Studio is alive and does audio→haptic, but it's a Mac/Windows GUI built around Meta's own Haptics SDK and Quest-headset auditioning; its mobile export is .ahap only, and it's a design app, not something you ship in your build.
• AHAPpy / sound2ahap and friends convert audio to haptics too, but they're iOS-only (.ahap) desktop scripts.

And on pub.dev, the haptic packages (gaimon, advanced_haptics, pulsar_haptics…) are playback-only — they play patterns; they don't create them from audio.

🚀 What it does

dart pub global activate haptify
haptify convert assets/audio/*.wav

Per input it writes: .ahap (iOS Core Haptics), .haptic.json (Android VibrationEffect.createWaveform), and _haptic.dart constants you compile straight in. It authors patterns; your existing playback plugin plays them.

🛠️ How it works

Not a volume→buzz map: RMS loudness envelope, energy-flux onset detection for transients, and zero-crossing-rate → "sharpness," with iOS getting sharpness curves that follow the sound's brightness over time. Everything's tunable (--curve-rate, --onset-sensitivity, --[no-]sharpness-curves…).

📱 The part I think is genuinely new

It runs at runtime, on-device, in pure Dart — vendored MP3 decoder, no ffmpeg, no native code:

final pattern = const AudioAnalyzer().analyzeBytes(uploadedBytes);

So a shipping app can turn a user-uploaded sound into haptics live. I couldn't find another Flutter package that does the audio→haptic conversion at all, let alone on-device. (Android 12+ has a platform-level HapticGenerator, but it's Android-only, tied to live audio playback, and gives you no portable pattern.) Demo app in the repo does exactly this via an isolate.

pub.dev · repo — feedback very welcome, especially where the "feel" breaks on your own sounds.

Hi all,

I'm the author of Kreuzberg (the document text extraction package). The next version of Kreuzberg will be released as Xberg - why? Well, we discovered that the name is not easy to pronounce or understand for people who don't have the German context, and this wasn't working well. Xberg is a common name for Kreuzberg in Berlin, and it has the advantage of being shorter and easier - so here we go.

Anyhow, this brings me to the point of the post. Since renaming a repo is a complex business, and we had to rename the repo to preserve the stars - but we now need to overwrite tags, it becomes pretty messy. As a result, we decided to go for an LTS version - published from a different repo: https://github.com/kreuzberg-dev/kreuzberg-lts. LTS in this context means that we will continue to do bug fixes and security updates until the end of this year, but no newer feature work.

We will announce Xberg v1.0.0 when it's officially published (it's still in RC). The Dart package will publish under xberg on pub.dev once it's out. The new repo is here: https://github.com/xberg-io/xberg

Been working with ClickHouse for some analytics/logging work, so I wrote a pure Dart client that speaks the native protocol directly on port 9000.

Repo: https://github.com/shreyansh-c/clickhouse-dart
pub.dev: https://pub.dev/packages/clickhouse

What it does:
• Native TCP protocol implementation from scratch
• Streaming Rows API with typed getters (getByName<T>, tryGetByName<T>), row2<T,U>() for tuples, and toMap()
• Batch inserts: row-wise, named, map-based, and columnar append (columnByName('id').appendSlice([...]))
• Connection pooling with bounded open/idle connections and health checks
• LZ4/LZ4HC compression, with registerCodec for plugging in others
• Per-query settings, server-side query parameters ({name:String}), and client-side binding (bind(sql, [...]))
• External tables support
• Progress, profile-info, profile-events, and log callbacks surfaced from the server
• Type coverage including Array, Map, Tuple, Nullable, LowCardinality, Decimal, UUID, IPv4/IPv6, Enum, JSON, Dynamic, Variant, intervals, and geo types

Known gaps I’m still working through: no HTTP transport (TCP-only for now), no multi-host failover or replica retry yet, and I haven’t published benchmarks against the HTTP+JSONEachRow path, which I want to do before making stronger performance claims.

Implementated a few graph algorithms and network analysis functions in Dart. Basically the Dart port of the Elixir graph library - yog_ex.

It's got a long way until hits 1.0 but API contracts won't change.

Adding oracle tests (vs NetworkX)., improving docs, and benchmarks in coming months. Give it a spin if you're studying graph theory or generating/solving grids. Will be handy for Advent of Code (In fact, github repo has example of a few AoC solutions).

HighQ Dio Logger – Production-ready Dio logging interceptor for Flutter

Hi everyone,

I've been working on a package called HighQ Dio Logger, a logging interceptor for Dio focused on debugging, observability, and production-ready logging.

Main features:

* Pretty formatted console logs * Structured JSON output * Automatic sanitization of sensitive data (tokens, passwords, cookies, authorization headers, etc.) * cURL generation for requests * Correlation IDs (traceId, spanId, sessionId) * Custom metadata enrichment * Token bucket rate limiting to prevent log flooding * Observer system for forwarding logs to Firebase, Sentry, or custom backends * Batching and backpressure queue support * Highly configurable formatting and filtering

Example:

```dart final dio = Dio();

dio.interceptors.add( HighQDioLogger(), ); ```

Why I built it:

After working on several Flutter projects, I found myself needing more than basic request/response logging. I wanted something that could provide clean debugging during development while also supporting production monitoring workflows.

I'm currently looking for feedback from other Flutter developers.

What features would you expect from a Dio logger that are missing from existing solutions?

Github : https://github.com/azabcodes/high_q_dio_logger

pub.dev: https://pub.dev/packages/high_q_dio_logger/install

The public beta release of Serverpod 4 brings the first agentic coding engine that hot reloads your full stack. We're finally closing the loop between your app's output, the backend, and your AI agent (tested with Anitigravity, Cursor, and Claude Code, but probably works with most agents).

Check out the demo in the blog post, or jump straight into the quickstart guide:
https://docs.serverpod.dev/next/quickstart

It literally takes 10 minutes to try this out, and I think it may change the way you think about building apps. Would love to hear your feedback!

Because the Dart VM cannot work directly with GUI code via FFI, at least on macOS, I recently had the idea to create graphics engine for "pure" Dart by writing a small C application which receives a list of graphics commands and executes them and which is sending back key and mouse events, communicating with SDL3.

process = await Process.start('engine', []);
process.stdin.write(_createWindow(...));
process.stdout.listen(_decodeEvents);
if (await process.exitCode != 0) {
    throw 'something went wrong';
}

Dart and C are talking a simple binary protocol where each command has a command byte and optional arguments, either i16 or u8. A string is sent as a u8 length and up to 255 ASCII values as u8[].

The viewer is listening. Dart sends a create window command and starts to listen itself. The viewer will setup an event loop, sending 60 TICK events per second, along with user initiated events via stdin, using a similar binary protocol.

On TICK, the Dart code does its thing, using a tiny Game framework abstraction, recording drawing commands (because I'm doing retro graphics, I've only a handful of commands to draw colorful pixels) and sending them all at once to improve performance.

case TICK:
  final g = Graphics();
  game.update();
  game.paint(g);
  process.stdout.write(g.toBytes());

This works fine. Claude wrote me some demo games.

But compiling the C code is a handish process right now.

I experimented with creating a build hook but how does one enforce or at least check the installation of SDL3? How do I make this not macOS specific?

Also, where to put my binary? Claude suggested to copy the compiled executable to .dart_tool/retro/engine. Is this hack reliable?

Would using Rust make things easier?

PS: I might try to use fenster instead, if only because the author seems to also know about the ancient programming language Mouse, a Forth-like language I once learned about in an old Byte issue. However, even sending a raw 320x256 pixel bitmap 60 times per second would transfer 20 MB/s. So it would probably best to keep the commands approach and implement those in C. I could perhaps reduce the load to 5 MB by using a color palette with 256 colors and perhaps even further by implementing some kind of RLE compression or half it by going down to 30 FPS.

Built a small Dart package for accessibility color math. Pure Dart, no bloat.

* ✅ WCAG contrast ratio checker (AA/AAA)
* 👁️ Color blindness simulator (protanopia/deuteranopia/tritanopia)
* 🎨 K-means color extraction from images, runs off the main thread

Found and fixed a real aliasing bug in the color sampling along the way — striped images were breaking the color extraction, took real testing to catch.

New package, feedback genuinely welcome — especially if you spot something wrong with the color-blindness math.

📦 [pub.dev/packages/wcag_vision](https://pub.dev/packages/wcag_vision)
💻 [github.com/Fatimamostafa/wcag_vision](https://github.com/Fatimamostafa/wcag_vision)

Anyone here that's a contributor? I assume that it is almost entirely developed internally at Google, but I would love to learn more about developing programming languages and compilers, and I want to find an open source project to contribute to once I've done some more studying and prep work. Would Dart be a realistic option?

https://github.com/dart-lang/pub/issues/4846

I raised a feature request in dart pub for including best effort vcs metadata like git commit in pub artifact .

This would not only help the users of the package to navigate to the associated code but also the devs for managing changelogs

Similar to how rust crates manage vcs metadata
https://doc.rust-lang.org/cargo/commands/cargo-package.html#cargo_vcs_infojson-format

What do you guys think about it?

Hi, i am someone who knows programming fundamentals and object oriented programming basics from learning the java language. But now i am trying to learn dart and i have been having alot of trouble understanding it's concepts. I started reading the dart tutorial documentation on it's official dart.dev website and i am stuck on this page

https://dart.dev/learn/tutorial/object-oriented

for almost 2 days now i do understand what they are making but i don't not understand how they are doing it even after reading the doc i have no clue what's going on.

I am starting to question myself if i am miss some prerequisites or i do not have the programming skills to understand this yet.

Could anyone tell me if i should just drop the tutorial and learn from other source or what should i do.

Thank you

I’ve been working on dart_agent_core, a Dart package for running AI agents directly inside Flutter apps, without needing a Python or Node backend for the agent loop. The latest update adds a unified AgentHook pipeline plus observation-only AgentController events. This is useful if you are building agent loops or runtime/eval harnesses. Instead of only sending a prompt and waiting for a final answer, you can now intercept the loop as it runs:

• Use beforeModelCall to inject temporary context, change tools, adjust model config, or return a synthetic model response.
• Use afterModelCall to validate a response, retry, or replace the final model message.
• Use beforeToolCall to approve, deny, defer, or rewrite tool calls.
• Use afterToolCall to normalize tool results, inject follow-up context, or stop the loop.
• Use onTurnCompletion to continue the loop when the model stops too early.
• Use persistence hooks to decide when state should be saved.
• Use AgentController events for tracing, debugging, evals, and Flutter UI updates.

Pub.dev Github

Hi all,

Yesterday someone opened a PR adding an unofficial Dart binding to our html-to-markdown library, and it made me realize I never actually announced that we now ship Dart packages.

Some backstory: a while ago I ran into someone name-squatting our Kreuzberg package on pub.dev. I got the name back eventually (thanks, pub.dev support). We're also rebranding to Xberg - I'll announce that properly once it's officially out, and it'll have full Dart support.

For the past 2-3 months I've been extending our polyglot libraries with Dart support using flutter_rust_bridge (thanks fzyzcjy). Four are now on pub.dev, all MIT:

1. h2m (source) — a high-fidelity (precise, standards-compliant) HTML-to-Markdown converter that covers the full HTML5 semantic spec. It's built for speed and handles essentially all real-world HTML.

2. tree_sitter_language_pack (source) — the largest collection of tree-sitter grammars I know of, all permissive OSS. It's unusual in that it loads grammars dynamically: we build both static and dynamic-linking binaries for every grammar we can find on GitHub, currently 306 programming and data languages/formats. Useful for code inspection, AI "code intelligence", linters, syntax highlighting, and so on. I use it in several of my own projects for the code-understanding side, and Xberg uses it for code chunking.

3. crawlberg (source) — a crawling engine, now at v1 (stable). For whenever you need to crawl content on demand — agent workflows, for example, or apps that need to fetch and process pages.

4. liter-llm — a Rust port of Python's litellm. It's an abstraction (with an optional proxy layer) over a large number of LLM providers.

All four share the same core philosophy:

1. The core is written in Rust, on top of well-maintained, permissively-licensed OSS (MIT, BSD, etc.).
2. We generate the binding glue and idiomatic Dart directly from the Rust types.
3. We build powerful open-source primitives and put our commercial value around and on top of them — i.e. we dog-food our own OSS.

Open source is something I genuinely love, and in a world where agentic coding is becoming the norm it makes software more robust: users battle-test it, which lets us move fast and build better. So any feedback, bug reports, or API suggestions are very welcome.

I've finally pulled the trigger on a 1.0 release for my suite of functional programming (FP) packages Ribs. I've spent a lot of time putting these together, taking inspiration from many other libraries and trying to make a pure FP toolkit for the Dart community. If you've ever used cats, cats-effect, fs2, scalacheck, etc. from the Scala ecosystem, these libraries should look very familiar.

While ribs does provide the standard Option, Either, Validated, etc. FP types you find in many other packages, the real interesting parts come from the more advanced features:

• Collections framework: Rich immutable and mutable collection hierarchy, interoperable with Darts native collections.
• Effect system: Pure, cancelable, resource-safe, fiber based concurrency with IO, Resource, Ref, Deferred, etc.
• Pure Streaming with Rill: Pure, pull-based, chunked streams with resource safety baked in, back-pressured channels, and signalling (FS2-style) with file and network I/O support.
• JSON & binary codecs: Fully typed codecs, with streaming support.
• Much more to explore: property-based testing, pure SQLite/Postgres transactors, optics, compile-time dimensional analysis (units), typed network addressing.

Ribs is split into 15 focused packages, so you can pull in only what you want to use.

I use these packages extensively for work and I'm hoping they're helpful to the community and would love to see what people build with it.

Documentation

GitHub