Configuration-to-Code

Apr 3, 2022

Look through any backend project and you'll find heaps of YAML or JSON files. It might be a verbose Kubernetes manifest. You won't find as many YAML files in a frontend project like a React App. Where's all the configuration then?

Most JavaScript (or TypeScript) projects simply use JavaScript as the configuration language. There are benefits to using a "real" language (turing complete) to write static (data) configuration.

  1. Code reuse – packages and imports aren't possible with YAML.
  2. For loops, variables, and value references – YAML has anchors, which let you reference another value in the file, but are notoriously difficult and error prone to use.
  3. Type safety and schema validation – you get type safety with TypeScript, and schema validation is doable in native JavaScript as well. YAML has no such guarantees.

Of course, YAML does have a few things going for it: it's easy to parse (no language runtime needed), and it's static representation is often close to its parsed representation.

There's projects like CUE to apply schema validation and basic code reuse (through file overlays), but I believe that simple configuration-as-code will win out in the end. It doesn't require users to learn a new format and it is much easier to use than complex configuration languages.

That's why I believe that we'll soon see a TypeScript frontend for Dockerfiles and that much of our configuration will find its way into JavaScript or TypeScript.