kareki 0.10.1

A multi-package dead code detector for Dart and Flutter monorepos. Finds unused public APIs, files, and pub dependencies across Melos / pub workspaces.

kareki

English | 日本語

枯木 (kareki): dead wood in Japanese — the unused branches that need pruning.

A workspace-wide dead code finder for Dart and Flutter. Unlike dart analyze, which only flags private unused declarations inside a single package, kareki resolves cross-package references across Melos / pub workspaces to surface the dead code that actually accumulates in real projects: public APIs no one calls, files nobody imports, and pub dependencies that ride along unused.

Using kareki? Please share your company and/or repository name in Issue #55 to help support an application for OSS development support from my employer. If you prefer to share privately, you can send a DM via the contact link in the issue.

Why kareki?

	What you get
🌲	Workspace-wide. Resolves references across every package in Melos / pub workspaces — not just one.
🔓	Public APIs too. Finds the public classes, methods, and fields dart analyze ignores.
🧬	Codegen-friendly. Built-in presets for freezed, json_serializable, riverpod, auto_route, go_router, drift, hive.
🧪	test_only_used. Catches lib/ code that only its own tests still use.
📉	Baseline. Adopt on legacy code without fixing everything first — CI fails only on new findings.
🩺	Doctor. kareki doctor flags stale ignore entries, dead excludes, and orphan suppression comments.
⚙️	CI-ready. JSON output, deterministic exit codes, portable baselines.

What it finds

Rule	Detects
unused_element	Public and private classes / functions / methods / getters / setters / fields / enums / enum values / top-level variables / extensions / extension types / typedefs / named constructors unreachable from workspace entry points.
unused_file	.dart files that are not import-ed, part-ed, or export-ed from any other file.
unused_pub_dependency	Packages declared in pubspec.yaml with no recognized source, analyzer configuration, native plugin, or font asset use.
test_only_used	Public declarations under lib/ that are only referenced from test code (*_test.dart, files under test/ or integration_test/). The implementation has no production consumer — typically its tests are the only thing keeping it alive.
unused_parameter	Parameters of a function, method, or named constructor that are never referenced in the body or initializers. Covers required and public-API parameters that Dart's built-in unused_element_parameter doesn't reach.
unused_parameter_optional	Optional parameters (named or positional optional) of a function, method, or constructor that are never passed at any call site in the workspace. The public / cross-package counterpart to Dart's built-in unused_element_parameter, which only inspects private optional parameters within a single library.
unused_l10n	Flutter gen-l10n template ARB keys with no resolved getter/method reference outside the localization outputs.
unused_asset	Flutter bundled assets, font families, and FlutterGen XML colors with no reference outside FlutterGen outputs.

Tool comparison

Feature	kareki	ciach	Dart Code Linter	dependency_validator	Dart standard analysis
Detect unused public declarations and members	✅	✅	✅	—	—
Detect unused private declarations and members	✅	✅	✅	—	✅
Detect unused values of public enums	✅	✅	✅	—	—
Detect cycles of public declarations unreachable from entry points	✅	—	—	—	—
Detect unused Dart files	✅	—	✅	—	—
Detect unused pub dependencies	✅	—	—	✅	—
Detect optional public API parameters never supplied by callers	✅	—	—	—	—
Detect public declarations used only by tests	✅	—	—	—	—
Dedicated unused-l10n checks	✅	—	✅	—	—
Report only new findings using a baseline	✅	—	—	—	—
Check stale exclusions and baseline entries	✅	—	—	—	—
Automatically remove unused public declarations	Not planned	✅	—	—	—

See the comparison details for required settings, limitations, and versions compared.

Install

# pubspec.yaml
dev_dependencies:
  kareki: ^0.10.1

dart pub get

Usage

Install the project's dependencies and run code generation, then execute from the workspace root:

dart run kareki

See the CLI reference for preparation, options, and analysis warnings.

Adopting on an existing codebase

You can adopt kareki without fixing all existing findings. Review the results, save them as a baseline, and commit it so CI reports only new findings:

dart run kareki --baseline .kareki-baseline.json --write-baseline

See doc/baseline.md.

Keeping the config honest

File moves and dependency changes can leave obsolete exclusions and suppressions. kareki doctor checks which entries no longer apply:

dart run kareki doctor

See doc/doctor.md.

Documentation

Browse the documentation site or read the Markdown sources directly:

• CLI reference — every option, every exit code
• Configuration — kareki-config.yaml, scope, suppression, presets, localization settings, defaults
• Baseline — incremental adoption
• Doctor — obsolete exclusions and suppressions
• How it works — analysis flow, entry points, limits, and supported versions
• Comparing similar tools — ciach, Dart Code Linter, and other Dart tools
• Best practices — scheduled cleanup pull requests with an AI agent

License

MIT. See LICENSE.