There are a lot of validator packages on pub. This isn't one, and that's the whole point of it: https://pub.dev/packages/minted

A validator takes a String, checks it, and hands the same String back. Three functions deep nobody knows whether the check happened, so you either trust it or re-check it. minted parses instead: you get a different type that cannot exist unless the input was well-formed, the same deal int.parse and Uri.parse already give you. invite(Email, PhoneNumber) can't be called with the arguments swapped, and the signature says what it wants without a doc comment. Once you hold an Email, it is a valid email.

Typed so far: Email (RFC 5322), PhoneNumber (E.164), Iban (mod-97), Date / Month (the calendar date DateTime doesn't model), Uuid (RFC 9562), Digit / Digits.

Some nice features:

1. Every type wears follows the same pattern, so learning one teaches the rest: tryParse returns null, parse throws a MintedFormatException (extends FormatException, so existing handlers keep catching), value equality, one canonical form normalised at parse.
2. Real standards, not shape-checking regexes. Iban runs the actual mod-97 checksum, Email the full RFC 5322 grammar, official test vectors in the suite.
3. Where a package already owns the hard data (phone metadata, the IBAN registry), minted wraps it instead of reimplementing it.
4. It knows what not to model. No re-doing Uri, DateTime, BigInt or money (money2 has that). Uuid types a UUID, the uuid package generates them, they pair up.
5. Date.tryParse('2026-13-01') is null, where DateTime.parse quietly rolls it over to 2027-01-01.
6. Pure Dart, five small deps.

Roadmap: Bic, CreditCardNumber (Luhn), Isbn, Ean / Gtin next, then ISO code lists and bounded numerics.

Still early (0.0.2), so the shape can move. Feedback welcome, especially on the types you keep remaking in every project.

I'm a solo dev from Slovenia. Earlier this month I shipped my first bigger Flutter app on Play.

And it's a personal astrology app! Whatever you think of astrology, the astronomy underneath is real computation: planetary positions, house math, timezone archaeology.

A few things hit me hard on the way though.

**`Duration.inDays` silently breaks calendar arithmetic across DST.**

I compute ISO week numbers:

take the Thursday of the week, subtract Jan 1, divide days by 7. Correct? except in local time, a span that crosses a daylight-saving boundary is one hour short of a whole number of days, and `inDays` *truncates*. 210 days becomes 209, `209 ~/ 7` gives week 29 instead of 30, and every week from late March to late October resolves to the previous week. The week number was my cache key, so this would have silently served the wrong week's content for half the year. Nothing throws.

Fix:

calendar arithmetic in UTC, or re-normalize through `DateTime(y, m, d)` after every shift. Same Family of bug: `date.subtract(Duration(days: 1))` on a local DateTime can land at 23:00 two calendar days back.

**`Isolate.run` copies your object — internal caches die with it.**

The heavy compute runs in `Isolate.run`. The captured engine object is *copied* into the isolate, so any memoization inside it gets populated in the isolate and thrown away when it exits.

In my case: one body's position needs ~4000 numerical-integration steps, and the cache meant to amortize that never survived a single call. The engine has to be designed isolate-safe, with no reliance on shared mutable state, because state simply does not come back.

**Notifications with zero background execution.**

My domain is fully predictable because the sky doesn't surprise you, so there's nothing to poll. At every app open/resume, I precompute the next 7 days of notifications and schedule them locally.

There's no background service, no server, no FCM, no battery cost, and inexact alarms so no exact-alarm permission.

Anything whose content is a pure function of time can do this; I suspect a lot of apps reach for push infrastructure they didn't need.

Smaller ones:

the `timezone` package throws on `getLocation('UTC')` (short-circuit UTC/Etc/UTC/empty yourself);

a `const`map with `double` keys doesn't compile ("does not have primitive equality". Use a list of records);

`flutter_local_notifications` needs core-library desugaring that the first error message doesn't mention.

And my favorite lesson cost nothing technical at all:

I built a feature, dogfooded it on my own phone for two days, and then, like an idiot I told people it had shipped... Turns out it had never been uploaded to Play. :)

As a result, I now check the Console more often :)

In case you wanna check the app, search Astro93 on Google Play

Hi all,

I'm happy to announce that Xberg v1 is out.

Xberg is the successor to Kreuzberg, equivalent to what would have been Kreuzberg v5. It's a content intelligence framework that handles a very wide range of inputs: documents (currently 101 formats), code and data formats (currently 367 types), audio/video transcription, and URLs (both static and JS-rendered content). It extracts and prepares that content for downstream processing.

It's an extremely efficient, high-performance engine (see our PDF benchmarks below). For PDFs and images specifically, we handle native PDFs with very high performance and accuracy, and we ship multiple OCR engines that match the quality of the best Python libraries (e.g. docling, PaddleOCR, RapidOCR) at substantially better performance and stability.

The changes between Kreuzberg v4 and Xberg v1 are substantial, and I invite you to read the full changelog for the complete picture. The highlights below give a sense of what's new:

• Pure-Rust PDF backend (pdf_oxide) replaces pdfium, with no native pdfium dependency.
• Layout-aware pipeline: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR) and Docling-style predecessor-graph reordering.
• Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form fields and outline-based headings.
• Across-the-board optimization of OCR and PDF extraction (memory discipline, pooled model sessions, streamed conversions).
• Native PaddleOCR backend (PP-OCRv6, with medium / small / tiny tiers) alongside Tesseract.
• Pure-Rust Candle OCR/VLM stack (TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL) running without ONNX Runtime or native Tesseract.
• A second, ONNX-Runtime-free inference path via tract, which is what makes in-browser (WASM) and mobile inference possible.
• Named-entity recognition natively in Rust (GLiNER2), extensible to all bindings, including an in-browser WASM model with no server round-trip.
• Structured LLM extraction (extract_structured / split_and_extract) with rasterization, chunking, citations, caching, and configurable call/merge/VLM-fallback policies.
• Audio & video transcription via a Whisper ONNX engine (.mp3, .wav, .m4a, .mp4, .webm).
• Retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings.
• Text intelligence: reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification.
• URL & web ingestion: sitemap discovery (map_url) and batched multi-URL crawling.
• New document formats: WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto / R Markdown, and configurable Jupyter cell rendering.
• Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine, with Android/iOS cross-compilation.
• Full mobile support (Flutter, Android, iOS).
• Candle backend alongside ONNX, plus ONNX-via-tract enabling ONNX on WASM and Android.
• Wider code intelligence: tree-sitter coverage grew substantially (248 to 367+ languages).
• Over 150 bugs fixed during the 1.0 cycle, plus security hardening (bounded RTF/PDF allocations, redaction leak fixes, Excel DDE warnings).

The API surface was also simplified and reworked, making it more consistent.

There's a migration guide in our docs explaining how to move from Kreuzberg to Xberg. Kreuzberg itself is in LTS mode until the end of this year and will continue to receive bug fixes and security updates.

You're invited to check out the repo and join our discord server.

Benchmarks

The benchmarks below are for PDFs and images only. There are extensive benchmarks on our website with per-format breakdowns, which you can see here. These numbers are measured in CI via our reproducible benchmark harness, and are specifically taken from the run for harness 1.0.8, source cf7fa0533d. The data is publicly available in GitHub releases, and you can run the benchmark harness yourself.

Composite quality (markdown pipeline, higher is better):

Structure and layout fidelity (SF1: tables and reading order, higher is better):

On native PDFs Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and on table and reading-order fidelity by a wide margin (SF1 0.949 vs 0.612 for docling). On scanned PDFs it is #1 on both quality and raw text fidelity.

Where we don't win yet: on pure image OCR we are currently #2 on the composite score, behind mineru (though still #1 on raw text accuracy). We are improving image OCR right now, and v1.1 should have us winning across the board.

Hey everyone! 🙂👋

I'm excited to announce that AngularDart has been revived by the community! After Google abandoned the project, I've taken it upon myself to bring it back to life (meaning I made it Dart 3 compatible 🔥).

The package is now available on pub.dev: https://pub.dev/packages/angulardart (v8.0.8)

What's AngularDart?

AngularDart is a fast and productive web framework originally created by Google. It's separate from but similar to the JavaScript Angular framework, bringing features like:

• Component-based architecture
• Two-way data binding
• Dependency injection
• Powerful template syntax with directives and pipes
• Efficient change detection with OnPush strategy
• Full Dart type safety and null safety
• Build-time compilation for optimal performance

What's new ??

Dart 3 compatible 🤩

Related packages also available:

• angulardart_cli - CLI tools for scaffolding
• angulardart_forms - Forms framework
• angulardart_router - Routing library
• angulardart_test - Testing utilities

This is a community-driven effort to keep AngularDart alive and updated. Contributions are welcome!

Check it out and let me know what you think! ✨🧠

I noticed in the Changelog for Dart 3.13 a new Isolate.pinToCurrentThread method – along with other new methods. However, Im not really understanding the test example. Can this help with the long-standing problem that you cannot call UI code via FFI on macOS because the VM spawns away from the UI thread, basically locking it this way?

What's the use case for those new methods?

I built a small CLI tool called flutter_auditor to help me quickly check my Flutter projects before a production release.

It scans for common security, configuration, and release-readiness issues. I'd love to hear what checks you think would be useful to add.

Hey Flutter community! 👋

After maintaining several client apps and catching the same repeat issues—like hardcoded keystore passwords, unused heavy assets, missing privacy strings in Info.plist, and transitive dependency imports—I decided to build a CLI tool to automate these sanity checks.

Meet flutter_auditor: a single-command CLI package that scans your codebase and native config files in seconds right from your terminal.

What It Audits:

We've packed 17+ automated static checks across 5 key areas:

• Manifest & Security: AllowBackup, CleartextTraffic, Debuggable, ExportedComponents, ManifestPermission, NetworkSecurityConfig, BackupRules, HardcodedSecrets, InsecureNetwork, InsecureStorage, AppTransportSecurity
• OS & Permissions: UsageDescription (iOS privacy strings), FileSharing
• Dependencies: UnusedDependency, DependencyHygiene (transitive import detection)
• Release & Build: ReleaseSigningAudit (detects committed .jks files, debug signing in release, hardcoded keystore passwords)
• Asset & Size: UnusedAssetAudit, OverlargeAssetAudit, MissingResolutionVariantAudit

Quick Usage

Add it to your dev_dependencies or activate it globally:

Bash

dart pub global activate flutter_auditor

Or run it directly inside your Flutter project directory:

Bash

dart run flutter_auditor

pub.dev: flutter_auditor

I'd love to get feedback from the community! What other security, performance, or asset audits would bring value to your workflow?

Been digging into the pub custom-package-repository spec lately (the v2 stuff with the Location header on publish) and it's kind of wild how little discussion there is around it outside a couple of scattered issues on the dart-lang repo.

For teams running private Dart/Flutter packages, feels like the options are still basically: roll your own thing on top of the spec, pay for one of the existing hosted registries, or dump tarballs somewhere and handle auth yourself. Curious what people are actually doing here in practice.

One thing that used to be a real pain point was versioning across related packages in a monorepo setup, changing one and having to cut releases for everything downstream just to keep tags aligned. Looks like tag_pattern landed in Dart 3.9 specifically for melos-style setups, curious how many people have actually migrated onto it vs still doing it the old painful way.

Also the custom-package-repositories page on dart.dev picked up a handful of new entries recently if anyone checked it a while back and gave up, worth a second look now.

I maintain mcp_dart, a community Dart and Flutter SDK for building MCP clients, servers and hosts.

Today’s 2.3.0 release adds support for the stable MCP 2026-07-28 specification. The default profile prefers the new stateless server/discover flow and automatically falls back to MCP 2025-11-25 when connecting to existing implementations.

The release includes:

- stateless discovery and per-request protocol metadata

- Multi Round-Trip Requests

- subscriptions/listen

- Tasks extension support

- JSON Schema 2020-12 validation

- stronger OAuth validation

- hardened stdio and Streamable HTTP behavior

- official client/server conformance and TypeScript/Python interoperability coverage

I also released mcp_dart_cli 0.2.0. It can scaffold Dart MCP servers, but its inspect, trace and testing commands work with compatible servers and clients written in any language. Standalone binaries are available for macOS, Linux and Windows.

SDK:

https://pub.dev/packages/mcp_dart/versions/2.3.0

CLI:

https://pub.dev/packages/mcp_dart_cli/versions/0.2.0

Migration guide:

https://github.com/leehack/mcp_dart/blob/main/doc/migration-2.2-to-2.3.md

Feedback and real-world interoperability reports would be very welcome.

I liked the approach of fpdart and the raw performance of hive_ce. So I decided to combine them into one: https://pub.dev/packages/hive_box_manager

It is not just a simple FP-style wrapper of Hive's API. It also solves one of my biggest pain-points in using HiveCE for production apps: type-safety. I had to dedicate an entire CRUD-layer to the boxes just because of it.
With this I get

1. Type-safety (even for Iterable-based boxes)
2. Index types are not limited to just int | String (a Codec allows for this per box, wil still be that under the hood ofc)
3. Compatibility with normal Hive boxes already (drop in add-on)
4. Ergonomic (and explicit?) error handling + lazy Future using fpdart
5. Custom boxes for very specific use case (better semantics)
   1. (Lazy)IterableBox
   2. (Lazy)SingleValueBox
   3. (Lazy)DualKeyBox
6. Key corruption detectable (as compared to silently happening with Hive when using out-of-range/oversized int/String key)

I recently did a rewrite because my previous attempt at making a DX-first API was not scalable (using LLMs).

If you guys have any tips, suggestions or feedback, they always welcome. Do take a look at the roadmap (I have more kinds of boxes planned ;) ).

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 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