Messagevisor

Workflow

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

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

Options reference

Core options

OptionTypeDefaultDescription
parserstring or objectymlFile parser to use. "yml" and "json" are built in.
namespaceCharacterstring.Separator between path segments in message keys
exportOverrideKeySeparatorstring":"Separator used in CSV exports for overrides (messageKey:overrideKey)
modulesarray[]Runtime modules for ICU, interpolation, etc.
setsbooleanfalseEnable multi-set project mode
promotionFlowsarray[]Restrict allowed set-to-set promotion directions
icuSkeletonbooleanfalseAllow inline ICU skeleton styles such as {amount, number, ::currency/USD} when ICU linting is active

Directory paths

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

OptionDefault path
localesDirectoryPathlocales
messagesDirectoryPathmessages
attributesDirectoryPathattributes
segmentsDirectoryPathsegments
targetsDirectoryPathtargets
testsDirectoryPathtests
datafilesDirectoryPathdatafiles
catalogDirectoryPathcatalog
exportsDirectoryPathexports
messagevisor.config.js
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

icuSkeleton is separate from modules. Registering createICUModule() enables ICU evaluation, while icuSkeleton: true loosens ICU style linting to allow inline skeleton styles:

messagevisor.config.js
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.

messagevisor.config.js
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.

messagevisor.config.js
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.

Previous
Projects
Next
Linting