Configuration

Messagevisor reads project configuration from root messagevisor.config.js. This file defines how the project is laid out, how definitions are parsed, and which modules are active.

Example#

const { createICUModule } = require("@messagevisor/module-icu");
module.exports = {
  modules: [createICUModule()],
};

Options reference#

Core options#

Directory paths#

All paths default to subdirectories of the project root. They can be overridden when your repository layout requires it.

module.exports = {
  messagesDirectoryPath: "src/translations/messages",
  datafilesDirectoryPath: "public/datafiles",
};

Directory overrides are useful when:

• integrating Messagevisor into an existing repository layout
• separating authored definitions from generated artifacts
• organizing sets or deployment outputs in a custom way

Parser configuration#

parser can point to:

• a built-in parser name such as yml or json
• a custom parser implementation

This lets the same project model work with different source file formats while keeping the rest of the workflow stable.

See Parsers for more information.

Modules#

modules define how runtime syntax is interpreted.

Typical examples:

• ICU message syntax
• interpolation

This matters in CLI and SDK runtime behaviour.

If a message behaves differently than expected, check modules before assuming the message text itself is wrong.

See Modules for more.

ICU skeletons#

lintIcu and icuSkeleton are separate from modules. Registering createICUModule() enables ICU evaluation. lintIcu controls whether messagevisor lint validates ICU syntax and named format references in message translations. It defaults to true:

module.exports = {
  lintIcu: true,
};

Set lintIcu: false only when a project intentionally stores text that looks like ICU but should not be validated by Messagevisor linting.

When ICU linting is enabled, icuSkeleton: true loosens style linting to allow inline skeleton styles:

const { createICUModule } = require("@messagevisor/module-icu");
module.exports = {
  modules: [createICUModule()],
  icuSkeleton: true,
};

Prefer named locale formats for shared product copy because they are easier to review and test across locales. Use inline skeletons when you deliberately need message-local ICU syntax.

Sets configuration#

Set sets: true to enable multi-set projects.

module.exports = {
  sets: true,
};

When sets are enabled:

• some CLI commands require --set
• definitions are organized under sets/<name>/...
• promotions become available as a dedicated workflow

Promotion flows#

Use promotionFlows to restrict allowed set-to-set movements.

module.exports = {
  sets: true,
  promotionFlows: [
    { from: "dev", to: "staging" },
    { from: "staging", to: "production" },
  ],
};

This keeps promotion commands aligned with your release model instead of letting any set copy into any other set.

Configuration and precedence#

Several runtime behaviors are shaped by both authored definitions and configuration:

• parser decides how files are read
• modules decide how message syntax is interpreted
• directory paths decide where the CLI reads and writes
• namespace configuration decides how file paths become keys
• export configuration affects CSV interoperability

Project configuration as managed in messagevisor.config.js does not replace authored data. It shapes how that data is discovered and interpreted.

Related#

• Projects
• Parsers
• Modules
• Datasource
• Sets
• CLI