Plugins

Messagevisor projects can inject extra CLI plugins through messagevisor.config.js. This is the escape hatch for project-specific workflows that should live beside the built-in commands.

Example#

module.exports = {
  plugins: [
    {
      command: "hello",
      handler: async () => {
        console.log("hello from a project plugin");
      },
      examples: [{ command: "hello", description: "run the hello plugin" }],
    },
  ],
};

Project plugins are appended to the built-in project-aware CLI commands.

Good use cases#

Plugins are useful when you need:

• project-specific export/import helpers
• validation or reporting commands
• internal workflow shortcuts

They are especially useful for organization-specific workflows around translations, for example:

• exporting review summaries for a localization vendor
• checking naming conventions that are too specific for core linting
• publishing datafiles to an internal service after build
• generating product-manager-friendly reports from the catalog JSON

What plugins should not replace#

If the behavior is part of the normal Messagevisor authoring model, it usually belongs in core definitions, tests, targets, or modules first.

Plugins are best for workflow-specific integration, not for replacing the content model.

Plugin shape#

A plugin has the same shape as built-in CLI commands:

• command: yargs-style command name
• handler: async function that receives project config, datasource, parsed options, and root path
• examples: command examples shown in CLI help

The handler runs with the loaded project configuration, so it can reuse custom paths, parser settings, sets configuration, and project datasource behavior.

Related workflows#

If the behavior changes message evaluation, write a module instead. If it validates authored entities, first check whether a test, lint, or schema rule is a better fit.

Related#

• CLI
• Configuration
• Modules
• Datasource