Datasource
The core package uses a Datasource abstraction so CLI commands can read and write project entities through one consistent interface. This is one of the main reasons the rest of Messagevisor can stay mostly format-agnostic.
What it exposes#
The datasource can:
- list, read, and write locales
- list, read, and write messages
- list, read, and write attributes
- list, read, and write segments
- list, read, and write targets
- list, read, and write tests
- read and write datafiles and revisions
Why it exists#
Datasource keeps core workflows from caring too much about:
- file layout details
- parser implementation details
- set-specific path resolution
That makes it easier for the rest of the CLI to focus on Messagevisor semantics instead of filesystem minutiae.
Default filesystem datasource#
Most projects use the default filesystem datasource. It reads entity definitions from the configured project directories:
locales/messages/attributes/segments/targets/tests/
The selected parser decides how each file is decoded. That is why the same project model can work with YAML or JSON starters.
When you should care#
Most users do not need to implement a datasource. You should care about it when:
- embedding Messagevisor in another tool
- experimenting with non-filesystem storage
- building an internal CLI plugin that needs to read project entities
- debugging custom directory paths or sets behavior
Sets support#
For sets-based projects, the datasource can create a set-specific view while keeping one shared top-level configuration model.
This is part of how commands like lint, test, build, and promote can operate cleanly across multiple definition trees.