Sets - Messagevisor

Sets let one project contain multiple parallel definition trees such as dev, staging, and production. They are Messagevisor's built-in model for multi-environment authoring workflows.

Initialize a new project with sets#

Quickest way is to make use of the CLI init command:

Command

$ npx messagevisor init --project=sets          # for two separate trees
$ npx messagevisor init --project=environments  # for linear promotion flow

This will scaffold a new project with sets enabled, and ready to use:

messagevisor.config.js

module.exports = {
  sets: true,
};

Structure#

The directory structure would look something like the following:

Directory structure

$ tree
.
├── sets
│   ├── my-first-set
│   │   ├── locales
│   │   ├── messages
│   │   ├── attributes
│   │   ├── segments
│   │   ├── targets
│   │   └── tests
│   └── my-second-set
│       ├── locales
│       ├── messages
│       ├── attributes
│       ├── segments
│       ├── targets
│       └── tests
├── messagevisor.config.js
└── package.json

Each set is a fully independent authoring tree. Files authored in sets/my-first-set/ do not interfere with those defined in sets/my-second-set/.

When to use sets#

Use sets when you need:

multiple parallel authoring trees
a promotion workflow (optionally)
parallel review or release lanes in one project repository

Do not use sets just because you have multiple applications. That is usually what Targets are for, to create separate targeted datafiles that SDKs consume.

Command behavior with sets#

Some commands run for all sets by default, while others accept or require --set.

Examples:

Command

$ npx messagevisor lint
$ npx messagevisor test --set=staging
$ npx messagevisor build --set=production
$ npx messagevisor prune --translations
$ npx messagevisor find-duplicates --set=staging

Operationally:

lint/test/build may run across all sets or be narrowed
find-duplicates scans all sets independently by default, or one set with --set
evaluate often requires --set in sets mode
promote move authored definitions between sets

Sets and promotions#

Sets become especially valuable when paired with:

promotionFlows in configuration
promote --from=... --to=...

That gives you a controlled "advance definitions through environments" workflow inside one repository.

Learn more in Promotions.

Edge cases and behavior notes#

Sets are separate authored trees#

They are not runtime flags layered on one common content pool. Each set can have genuinely different authored definitions.

Targets still matter inside sets#

Sets and targets solve different problems:

sets model parallel authoring trees
targets model output slices inside a given set

Many real projects need both.