Skip to content
MAATDocumentationLatest

Community Extension Checklist

Maat extensions are ordinary packages: a MaatExtension, a VizierExtension, or both, opted into by name through withExtensions or Panel(extensions:). Nothing scans pub.dev, and nothing installs itself. This checklist is the bar a package clears before it is worth linking from Community Extensions — a reviewer’s judgment call, not an automated gate.

An extension author self-reports against this list. A reviewer confirms each item before the package is added to the directory.

  1. Public APIs only, explicit activation. The package imports only the public surface of maat, vizier, and any other package it extends — no src/ reach-through. It registers nothing on its own: an application opts in by passing the extension to withExtensions or Panel(extensions:).
  2. Namespaced everything. Routes, commands, config keys, view names, and translation keys are prefixed so they cannot collide with an application’s own or with another extension’s. Any database objects (tables, migrations) are named the same way.
  3. Security review of what it exposes. Every route the package registers states the middleware it expects (authentication, authorization) and does not assume the application will supply it silently. State-changing routes carry CSRF protection or a documented exemption. Output rendered into views is escaped, not written past the view engine’s autoescaping.
  4. Documented install, rollback, and removal. The README says what an application adds to opt in, what running vizier:install or an equivalent publishes, and what to delete or revert to remove the package cleanly — including any published views, assets, or migrations.
  5. No hidden behavior. No telemetry, no phone-home update checks, no remote code execution or dynamic code loading. Everything the package does is visible in its source and triggered by the application’s own calls.
  6. License, changelog, and version discipline. A LICENSE file, a CHANGELOG.md that describes each release, a semantic version in pubspec.yaml, and a stated compatibility matrix against Maat and Dart SDK versions.
  7. A real security-reporting path. The package’s repository documents how to report a vulnerability privately — a SECURITY.md, a security contact address, or an equivalent that a reporter can actually use. A link to a repository with no such path does not satisfy this item.
  8. Runnable proof. An example/ (or equivalent) application that exercises the extension end to end, plus evidence that dart analyze --fatal-infos, dart test, and dart pub publish --dry-run all pass in the package directory. A directory entry links to that evidence (CI run, or reproducible local commands) rather than asserting it.

None of this is enforced by tooling against packages outside this repository. It is what a reviewer checks by hand before adding a row to Community Extensions.