Configuration

The YAML editor is for the files that set up services and applications - deployment manifests, settings, environment files. It reads YAML (1.2 or 1.1), TOML, INI, Java .properties and .env. Edit the file as text, with colouring, folding and completion, or as a tree, changing values and keys in place and adding, moving, duplicating and commenting out entries; and compare it with another version side by side.

Give it a JSON Schema - one for the whole file, or one per document chosen by what the document holds - and every broken rule is underlined where it is, in plain words, and listed in a problems panel. Anchors, aliases and merge keys are shown and followed. An edit changes only the characters it must, so comments, quoting and blank lines stay as they were; Format lays YAML out again and keeps every comment. Convert to JSON or to any of the other formats in a click.

Try it with your own configuration files in confidence: they are opened by your browser, on your device. Nothing is uploaded, no copy reaches us or anyone else, and nothing is kept once you close this tab.

A deployment, checked against its schema

A made-up ferry company's ticket service, as three documents in one file - a deployment, a service and its settings - each checked against an invented schema for its kind (not a real Kubernetes schema). The labels are an anchor used twice and the receipts worker's resources come through a merge key. Today's edit left two mistakes: go to the first, then put them right, and compare the file with yesterday's.

Go to the first problem

Put it right

Show it as a tree

Format

Show it as JSON

Compare with yesterday's

Put it back

Keyboard: in the text, Ctrl+Space offers the keys and values the schema allows at the caret. In the tree, the arrow keys move and open, Enter edits a value, F2 renames, Insert adds, Ctrl+D duplicates, Delete deletes and Shift+F10 opens the actions.

// Node 18 or later, from the Pro or Gold package: check every configuration file in CI and fail the build on a problem.
import { readdirSync, readFileSync } from 'node:fs';
import { checkConfigText, detectConfigFormat } from './dist/node/bmx-yaml-editor.mjs';

const schema = name => JSON.parse(readFileSync(`schemas/${name}.schema.json`, 'utf8'));
const rules = [
  { match: { kind: 'Deployment' }, schema: schema('deployment'), name: 'Deployment' },
  { match: { kind: 'Service' }, schema: schema('service'), name: 'Service' },
  { match: { kind: 'ConfigMap' }, schema: schema('settings'), name: 'Settings' },
];
let failed = 0;
for (const name of readdirSync('config')) {
  const format = detectConfigFormat(name);
  const { ok, problems } = checkConfigText(readFileSync(`config/${name}`, 'utf8'), format, format === 'yaml' ? rules : null);
  for (const p of problems) console.log(`config/${name}:${p.line}:${p.column} ${p.severity}: ${p.message}`);
  if (!ok) failed++;
}
process.exit(failed ? 1 : 0);

One settings file, four formats

An invented appointments app's settings, written as TOML with comments. Add to the database pool and only that number changes - the comments and the layout around it stay. Then convert the file to INI, Java .properties or .env and see how each format writes the same settings.

Add 5 to the pool

Convert to INI

Convert to .properties

Convert to .env

Back to the TOML

Get the code

<script src="/assets/bmx-components.min.js"></script>

<bmx-yaml-editor id="cfg-set" label="Appointments app settings" file-name="wrenfield.toml" style="inline-size: 100%; --bmx-yaml-editor-height: 20rem"></bmx-yaml-editor>