Alternative config format(s)

[tj]

Not a priority at all but:

[samusgray]

Oops. I didn't realize that clicking would submit my vote, so I voted for TOML. I've never heard of TOML and JSON is fine, in my opinion :D

[tj]

I don't mind TOML until it gets to more complex arrays, that gets pretty unintuitive unless you specify it like this which looks weird IMO. Not sure how you express that "properly" in TOML

name = "api"
description = "Some API for whatever"

[hooks]

build = "make build"
clean = "make clean"

[environment]

FOO = "here"
BAR = "here"

[cors]

allowed_origins = ["example.com"]
allowed_methods = ["GET"]
max_age = 123123

[lambda]

memory = 1024
timeout = 5

[dns]

zones = [
  {
    name = "apex.sh",
    records = [
      {
        name = "blog.apex.sh",
        type = "CNAME",
        ttl = 300,
        value = ["......."]
      }
    ]
  }
]

[tj]

could see YAML getting unwieldy too, maybe need to re-shape some of the config to suit these better later

name: "api"
description: "Some API for whatever"

hooks:
  build: "make build"
  clean: "make clean"

environment:
  FOO: "here"
  BAR: "here"

cors:
  allowed_origins: ["example.com"]
  allowed_methods: ["GET"]
  max_age: 123123

lambda:
  memory: 1024
  timeout: 5

dns:
  zones:
    - name: "apex.sh"
      records:
        - name: "blog.apex.sh"
          type: "CNAME"
          ttl: 300
          value: ["...."]

[tj]

shit I forgot one, markdown! https://github.com/tj/mdconf

[lukeed]

Voted for JSON. Yaml is next best alternative. Your markdown conf is third simply because it looks cool 😆

[olivoil]

Voted for HCL. My only experience with it is with terraform, but it's the best config format I've tried so far. So much better than CF's yaml or json files both when reading and writing

[tj]

I like HCL too, great for arrays, I haven't tried it outside of TF yet, not sure if you can specify root-level vars? I'll have to mess around with that later

[olivoil]

I think this is the way they're handled in terraform: https://github.com/hashicorp/hcl/blob/master/test-fixtures/decode_tf_variable.hcl

So, you'd likely need to support declaring them in json like:

{
    "variable": {
        "name": {
            "default": "api",
            "description": "project name"
     }
}

[tj]

ah bummer, that's not too nice

[olivoil]

@tj nevermind that, it actually supports top-level variables and looks pretty good.

name = "api"
description = "Some API for whatever"

hooks {
  build = "make build"
  clean = "make clean"
}

environment {
  FOO = "here"
  BAR = "here"
}

cors {
  allowed_origins = ["example.com"]
  allowed_methods = ["GET"]
  max_age = 123123
}

lambda {
  memory = 1024
  timeout = 5
}

dns {
  zones = [{
    name = "apex.sh"
    records = [{
      name = "blog.apex.sh"
      type = "CNAME"
      ttl = 300
      value = ["......."]
    }]
  }]
}

Made a quick gist to show what it would look like with a main.go that outputs the result in json if you want to test: https://gist.github.com/olivoil/1348a7e78db264c5e6ca876140fb1948

[tj]

sickkk

DNS could be

dns {
  zone {
    name = "apex.sh"
    record {
      name = "blog.apex.sh"
      type = "CNAME"
      ttl = 300
      value = ["...."]
    }
  }
}

or something like

dns {
  zone "apex.sh" {
    record "blog.apex.sh" {
      type = "CNAME"
      ttl = 300
      value = ["...."]
    }
  }
}

hmm need to think about pluralization to make sure it'll be nice for both

[harlow]

will the files be compossible? mixing general config options w/ ENV secrets feels odd to me (i'd want to be able to gitignore any ENV)

[olivoil]

I like the second option for DNS with singular names and maps with the name as the key, it feels more idiomatic after working with TF.

HCL doesn't have any built-in mechanism to include other files by itself, but it shouldn't be too hard to implement. It could be something like environment = "${file(secret.json)}" like TF does, or reading all files in a config folder maybe and you could just add the one you don't want to commit to .gitignore

[tj]

@harlow .environment is just for non-secret env vars, secrets will need an alternative, but since Lambda env vars are immutable (shipped w/ the Lambda) having up env set .. etc won't work unless I roll my own on top of KMS (totally feasible). Opened an issue for it #90

[nitely]

Something that allows comments (i.e not JSON)

[rdonkin]

Agree with @nitely - the fact that you can't add comments to JSON is a major drawback. I can live with the picky syntax and too much quoting, just about, but I would prefer YAML (preferably the StrictYAML subset).

TOML would be OK but isn't as readable as YAML - StrictYAML simplifies YAML making it easier to parse, while still solving some problems with TOML.

[kaihendry]

Heard of JSON5? It's like JSON, less strict and can handle comments. :boom: