A plugin for managing other plugins in the Hiero CLI system.
This plugin provides functionality to add, remove, list, and get information about plugins in the system. All commands return structured CommandResult with both JSON and human-readable output formats.
Add a new plugin to the system. Use --path for custom plugins or --name for default plugins.
Options:
--path, -p(optional): Filesystem path to the plugin directory containingmanifest.js--name, -n(optional): Name of a default plugin to add (e.g. account, token). Use--pathfor custom plugins.
Exactly one of --path or --name must be provided.
Examples:
# Add a custom plugin from path
hcli plugin-management add --path ./dist/plugins/my-plugin
# Add a default plugin by name
hcli plugin-management add --name accountRemove a plugin from the system.
Options:
--name, -n(required): Name of the plugin to remove
Example:
hcli plugin-management remove --name my-pluginList all available plugins in the system.
Example:
hcli plugin-management listGet detailed information about a specific plugin.
Options:
--name, -n(required): Name of the plugin to get information about
Example:
hcli plugin-management info --name accountEnable a plugin that exists in the plugin-management state.
Options:
--name, -n(required): Name of the plugin to enable
Example:
hcli plugin-management enable --name accountDisable a plugin that exists in the plugin-management state.
Options:
--name, -n(required): Name of the plugin to disable
Example:
hcli plugin-management disable --name accountClear plugin-management state. Custom plugins will be removed. This is a destructive operation and requires confirmation.
Options:
- None
Example:
hcli plugin-management resetThe plugin-management state is stored in ~/.hiero-cli/state/plugin-management-storage.json. It contains:
Plugin entries – one key per plugin (e.g. account, token, network), each with:
name,enabled,description, and optionallypathfor custom plugins
initialized-defaults – metadata key (always first in the file) listing default plugin names that have been initialized at least once. Used to:
- Add new default plugins when they appear in
DEFAULT_PLUGIN_STATE(e.g. after a CLI update) - Avoid re-adding default plugins that the user explicitly removed
Auto-initialization: On each CLI start, any default plugin from DEFAULT_PLUGIN_STATE that is not in initialized-defaults is added to the state and to initialized-defaults. Default plugins removed by the user stay removed.
Custom plugins are never added to initialized-defaults; they are fully removed from state when the user runs remove.
All commands support both JSON and human-readable output formats:
- JSON: Structured data for programmatic use
- Human-readable: Formatted text for terminal display
All commands return structured output through the CommandResult interface:
interface CommandResult {
result: object;
}Output Structure:
- Command Handlers: Return
CommandResultobjects - Output Schemas: Defined using Zod for validation and type safety
- Templates: Handlebars templates for human-readable output
- Error Handling: Consistent error handling across all commands
The result field contains a structured object conforming to the Zod schema defined in each command's output.ts file, ensuring type safety and consistent output structure.
src/plugins/plugin-management/
├── commands/
│ ├── add/
│ │ ├── input.ts
│ │ ├── handler.ts
│ │ ├── output.ts
│ │ └── index.ts
│ ├── remove/
│ │ ├── input.ts
│ │ ├── handler.ts
│ │ ├── output.ts
│ │ └── index.ts
│ ├── reset/
│ │ ├── handler.ts
│ │ ├── output.ts
│ │ └── index.ts
│ ├── list/
│ │ ├── handler.ts
│ │ ├── output.ts
│ │ └── index.ts
│ ├── enable/
│ │ ├── input.ts
│ │ ├── handler.ts
│ │ ├── output.ts
│ │ └── index.ts
│ ├── disable/
│ │ ├── input.ts
│ │ ├── handler.ts
│ │ ├── output.ts
│ │ └── index.ts
│ └── info/
│ ├── input.ts
│ ├── handler.ts
│ ├── output.ts
│ └── index.ts
├── schema.ts # Shared data schemas
├── manifest.ts # Plugin manifest
├── index.ts # Main exports
└── README.md # This file
- All handlers return
CommandResultobjects - Output schemas are defined using Zod for runtime validation
- Human-readable templates use Handlebars syntax
- Mock data is used for demonstration purposes
- Real implementation would integrate with the plugin manager service