fart_style is a drop-in fork of dart_style that formats code using SmartTabs instead of 2-space blocks, while keeping the rest of Dart’s formatting rules intact.

I made fart_style because it has become hard for me to read 2 space idents with my ever worsening eyesight. Exacerbated by the fact that flutter code gets nested into hell and beyond.

I've been running it across all my projects for a few months now and figured others might find it useful.

Ironic note: the repo itself still uses dart_fmt so I don't lose my mind resolving merge conflicts with upstream updates.

Package: https://pub.dev/packages/fart_style
Source: https://github.com/Curstantine/fart_style

Hope it saves some eyes!

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?

Hi! I wanted to share a new package I made: terminice.

I built it because creating a beautiful, complex CLI shouldn’t mean building an entire terminal UI from scratch. It should be easy to create, easy to style, easy to manage as it grows, and most importantly easy and enjoyable for people to use.

terminice turns more than 30 common terminal interactions into small method calls, with no setup and no framework required.

Here is the visual demo.

Need a value from the user?

final name = terminice.text('Project name');

Need a searchable menu?

final template = terminice.searchSelector(
  prompt: 'Template',
  options: ['CLI', 'Server', 'Package'],
);

Need a file browser, config editor, command palette, progress bar, multi-step form, calendar, or help center? those are method calls too.

There is no setup, widget tree, context object, or new application architecture. import the package, call the component you need, and keep using package:args, CommandRunner, dart:io, or whatever already powers your CLI.

dart pub add terminice

Make the entire CLI look like yours

Don’t like the borders? hide them:

final t = terminice.minimal;

Want the borders, but fewer hints and less visual noise?

final t = terminice.compact;

Want different colors? Pick a built- in theme:

final oceanUi = terminice.ocean;
final matrixUi = terminice.matrix;
final neonUi = terminice.neon;
final arcaneUi = terminice.arcane;

Or combine everything:

final t = terminice.neon.compact;

Now every component created from t follows the same style:

final name = t.text('Project name');
final token = t.password('API token');
final config = t.filePicker('Config file');
final confirmed = t.confirm(message: 'Create the project?');

>(you can also create a fully custom, advanced theme, and it will automatically be used across all 30+ components!)

That is one of the main ideas behind terminice: customize the instance once, and the colors, borders, glyphs, display mode, fallback behavior, and terminal I/O stay consistent across the entire CLI.

You can also create a custom theme in a few seconds by mixing the included colors, glyphs, and display features:

final brandTheme = PromptTheme(
  colors: TerminalColors.ocean,
  glyphs: TerminalGlyphs.rounded,
  features: DisplayFeatures.compact,
);

final t = terminice.themed(brandTheme);

Need finer control? Every color palette, glyph set, and display configuration supports copyWith, so you can change one accent color or one behavior without rebuilding the rest of the theme. The custom theme then affects prompts, menus, pickers, progress indicators, flows, guides, and every other built-in component.

The catalogue

Terminice currently includes more than 30 ready to use components:

Prompts

• text for single-line input
• password for masked input
• confirm for yes/no questions
• multiline for terminal text editing
• slider and range for numeric input
• rating for star-based ratings
• date for keyboard-driven date input
• form for collecting multiple fields together

Selectors

• searchSelector for long, filterable lists
• choiceSelector for card-style single or multi-select choices
• checkboxSelector for checklists
• gridSelector for two-dimensional navigation
• tagSelector for managing multiple tags
• toggleGroup for editable boolean settings
• commandPalette for a fuzzy-searchable action launcher

Pickers

• filePicker for browsing files
• pathPicker for choosing directories
• colorPicker for interactive ANSI color selection
• datePicker for a full calendar interface

Progress and status

• Full and inline loading spinners
• Full and inline progress bars
• Minimal dot-based progress
• info, success, warn, error, detail, and log messages
• task for wrapping async work with a status indicator
• progressTask for determinate async work
• trackStream for collecting a stream while showing its progress

Complete CLI experiences

• flow for multi-step workflows with context, conditions, validation, and review
• configEditor for searchable, nested application settings
• cheatSheet for quick-reference tables
• helpCenter for searchable documentation inside the terminal
• hotkeyGuide for keyboard shortcut discovery
• themeDemo for previewing themes and colors
• Custom components when your CLI needs something package-specific

Every catalogue item has its own detailed documentation with controls, behavior, examples, and API notes. I wanted the README to be useful as a practical reference, rather than leaving developers to discover important behavior through trial and error.

The vision

The goal is not only to make prompts look better. I want Terminice to make beautiful, complex CLIs easier to create, style, manage, test, and use.

to create: add prompts, selectors, pickers, progress, or configuration screens with small method calls. not a new architecture.

to style: choose or create one theme, and let the entire CLI follow it. no repeating colors, borders, glyphs, and display options everywhere.

to manage: keep components, behavior, fallbacks, and tests consistent as the CLI grows.

to use: give people clear hints, predictable controls, validation, cancellation, readable fallbacks, and good defaults.

terminice sits between a prompt package and a full TUI framework. It is the human facing layer of an existing dart CLI: questions, choices, files, settings, progress, and feedback.

It can stay tiny when tiny is all you need:

final email = terminice.text('Email');

That same CLI can later grow into searchable menus, filesystem navigation, validation, progress tracking, configuration screens, or complete flows- without switching packages.

When rich UI is not appropriate, the built-ins can fall back to predictable plain text for limited terminals, non-TTY output, scripts, and unattended execution.

Terminal IO is abstracted as well, so you can easily test without depending on real stdin/stdout.

So the short version is:

• One import and no setup
• 30+ components covering individual prompts through complete CLI workflows
• 11 built-in style presets
• Chainable themes and verbose, compact, or borderless minimal display modes
• One shared configuration across the whole CLI
• Custom themes and components when the built ins are not enough
• Cross-platform support for Linux, macOS, and Windows
• Predictable fallbacks and test utilities for real-world use

Links:

• Visual demo
• terminice on pub.dev
• GitHub, documentation, and the full catalogue

A small personal note

I started working on what eventually became terminice over a year ago, it didn’t begin as one big, carefully planned package. While working on real projects, I kept creating terminal components that I needed- a prompt in one project, a selector in another, a progress indicator somewhere else, then themes, flows, config tools, and testing helpers.

For a while, all of that work was scattered across different projects. Gradually, I started moving the useful pieces into one place, redesigning them around a shared API, and turning them into a unified, robust tool that is genuinely fun and easy to use.

The package is not perfect. there are still many things that need refinement, and probably many things I cannot see because I built them around my own use cases. I want terminice to be the best tool it can, but I know I cant do that alone.

I would really appreciate it if you tried it, even in a small project, and told me what you think. If an API feels awkward, a component is missing, the documentation is unclear, or something simply doesnt feel right, I want to hear about it- every bug report, idea, criticism, and any feedback is appreciated (:

I'm sorry, but how is any non-expert supposed to understand how to use hooks? Have any of you, after studying the rather sparse documentation and complex Hooks API, actually felt like you understood any of this? I have been sitting here for hours, just trying to call a simple function from a pre-compiled dll, but the non-helpful documentation and error messages make even the simplest things a daunting task.

But what I find most unpleasent is that even the basic example code (which hasn't helped me at all) looks quite complex and build hooks can just execute any arbitrary code, be that downloading files, executing some other script, or whatever. Not only does that stink of a huge security risk, but there will be so many packages with completely broken hooks on pub, which will then also start to depend on each other. This will be really fun...

Edit: Heureka, it finally worked! But what a frustrating ride it was...