YAML and Configuration Files

• strictyaml

  21 1,421 1.9 Python

  Type-safe YAML parser and validator.

I do think some of the more "advanced" features are definitely a mistake. StrictYAML (https://github.com/crdoconnor/strictyaml) is a limited, much saner subset of YAML that I wish people would use more: https://hitchdev.com/strictyaml/features-removed/

No coercion of y/n/yes/no/on/off to booleans (these were also removed in the official YAML 1.2 spec, thankfully), no direct object representations, no anchors or references, etc.

• json5

  96 6,330 0.0 JavaScript

  JSON5 — JSON for Humans

  

YAML (and JSON in general) has the big advantage, that you can use JSON Schema to validate it and to provide realtime code intelligence in many Editors (VScode, IntelliJ, Monaco Editor in the web, many Web IDEs).

So it's easy to hate on YAML or on JSON, but it's hard to throw out the rich ecosystem along with them they already have established.

One format I personally like is JSON5 (https://json5.org/) as it's very much just JSON, but with some more modern JavaScript (ES5) syntax allowed, including comments. Looks like a parser / serializer for it is also still rather consise.

Although, I'm always wondering which features of YAML to best not use / touch. My personal approach would have been to leave some advanced features to optional pre-processors or real programming / template languages.

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• json5-go

  1 32 0.0 Go

  Discontinued The official implementation of JSON5 for the Go language

  

• cue

  28 3,181 9.1 Go

  Discontinued CUE has moved to https://github.com/cue-lang/cue (by cuelang)

  

I think Cue[1] is a much more powerful and useful config format that also has the ability to generate validated JSON or YAML if needed.

[1]: https://cuelang.org

• KeenWrite

  98 621 0.0 Java

  Discontinued Free, open-source, cross-platform desktop Markdown text editor with live preview, string interpolation, and math.

My text editor, KeenWrite[0], integrates YAML using a GUI, which hides the underlying data format[1]. This makes the format irrelevant from the end user's perspective. Nobody edits .odf files or .png files directly, yet configuration files are often updated in a plain text editor rather than a GUI.

[0]: https://github.com/DaveJarvis/keenwrite/blob/master/docs/scr...

[1]: https://youtu.be/u_dFd6UhdV8?t=160

• ytt

  14 1,605 7.0 Go

  YAML templating tool that works on YAML structure instead of text

  

This is why you should consider https://carvel.dev/ytt/

• libyaml

  1 901 3.6 C

  Canonical source repository for LibYAML

  

Currently, my main concern with YAML is that, by the spec, comments are not attached to a particular node (see https://yaml.org/spec/1.2/spec.html#id2767100). As a result, a lot of YAML parsers (like https://github.com/yaml/libyaml and https://github.com/chyh1990/yaml-rust) only filter out the comments during the parsing phase. This makes it less than ideal for a use-case where the configuration file is expected to be modified by both programs and humans.

TOML makes it more trivial to associate comments with a node. This is mainly because the language is simpler though, as the spec is not explicit about that (https://github.com/chyh1990/yaml-rust).

• SaaSHub

  www.saashub.com featured

  SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  

• yaml-rust

  4 597 0.0 Rust

  A pure rust YAML implementation.

Currently, my main concern with YAML is that, by the spec, comments are not attached to a particular node (see https://yaml.org/spec/1.2/spec.html#id2767100). As a result, a lot of YAML parsers (like https://github.com/yaml/libyaml and https://github.com/chyh1990/yaml-rust) only filter out the comments during the parsing phase. This makes it less than ideal for a use-case where the configuration file is expected to be modified by both programs and humans.

TOML makes it more trivial to associate comments with a node. This is mainly because the language is simpler though, as the spec is not explicit about that (https://github.com/chyh1990/yaml-rust).

• hjson-js

  9 405 0.0 JavaScript

  Hjson for JavaScript

  

well there are json alternatives which fit this bill, such as HJSON.

https://hjson.github.io/

might not be as "common" but it has good implementations for many languages.

• skylark

  1 1,184 0.0 Go

  Discontinued Skylark in Go: the Skylark configuration language, implemented in Go [MOVED to go.starlark.net]

  

My stance is that YAML is a good format for configuration management and generation -- it's wonderful at filling gaps as your deployment model increases in complexity to provide a mechanism to "render" your configuration -- much like Skylark [1] does (derived from Google's internal GCL).

YAML ends up being a powerfully declarative model [2] for the state of a data structure, rather than a straight representation, ironically often enough being used in turn for an imperative model like in Ansible [3]. Definitely friendlier than JSON. But personally, I really like YAML because it lets me compose using a traits/mixins-like model using & and , which allows for verbose, structured configuration inputs but concise configuration files.

docker-compose YAML files extension fields [4], imo, are a great example of this type of model in action. When you leave this much pre-deserialization flexibility in your configuration representation, it makes building cool stuff like docker-compose ECS support x-aws- extension keys [5] and other plugin system-type capabilities much more straightforward than, for example, adding a new language feature to HCL.

[1]: https://github.com/google/skylark

Suggest a related project