.yaml, .toml, etc?

  • pileghoff@programming.dev
    16·
    2 years ago

    I usually use Json5. It’s JSON, but with all the weird quirks fixed (comments added, you can use hex numbers, you can have trailing commas etc.)

  • AverageCakeSlice@sh.itjust.works
    143·
    2 years ago

    JSON by a mile. I hate the YAML plague, it’s some of the most unintuitive syntax I’ve seen and yet it’s everywhere in DevOps/SysOps.

    • Magnus Åhall@lemmy.ahall.se
      2·
      2 years ago

      YAML here as well.

      Configuration many levels deep gets so much harder for me to read and write in JSON with all [], {} and “”

      Also the lack of comments… And YAML still is more used in software I’m using than JSON5, so I’d rather skip yet another format/library to keep track of.

    • argv_minus_one@beehaw.org
      1·
      2 years ago

      Please do not use YAML. It’s a syntactic minefield. It also doesn’t allow tab indentation, which is supremely irritating.

  • Andy@programming.dev
    6·
    2 years ago

    https://nestedtext.org/

    It’s like yaml but simple, consistent, untyped, and you never need to escape any characters, ever.

    Types and validation aren’t going to be great unless they’re in the actual code anyway.

  • Edo78@feddit.it
    61·
    2 years ago

    It really depends. I usually prefer json. It’s easily understandable from humans and from machines, it doesn’t depends on indentation and above everything else I like it very much 🤣

  • simonced@lemmy.oneEnglish
    1·
    2 years ago

    A lot of good answers but I would add one note:

    • use a format that supports comments, and JSON is not one of those…
    • AeroLemming@lemm.eeEnglish
      0·
      2 years ago

      Of course it does!

      {
  comment: "This data is super important and it runs the system or something",
  data: ["Some", "stuff", "here"]
}
        • AeroLemming@lemm.eeEnglish
          2·
          2 years ago

          Please don’t actually do this. Comment stuff in the code and documentation, not the JSON.

          • sfera@beehaw.org
            1·
            2 years ago

            Don’t worry, I wouldn’t do things like this in JSON. Nevertheless, it can be very useful to have comments along with configuration values, for example to explain the actual values (not their purpose) and why they were chosen. That’s information you can’t add to the code which processes the values.

  • vrkr@programming.dev
    1·
    2 years ago

    No reason to go beyond simple key-value format like dotenv or just env variables. If you need more structure then maybe you are confusing configuration with state and this is not really the same thing.

  • spartanatreyu@programming.dev
    1·
    2 years ago

    It depends what you need your configuration file to be:

    Need a well defined easy to understand concrete configuration file?

    • Use .toml. It was made to be both human and computer friendly while taking special attention to avoid the pitfalls commonly found in other configuration files by explicitly stating expected types around commonly confused areas.

    Need a simple to implement configuration file?

    • Use .json. It’s famous for being so simple it’s creator “discoverer” could define it on a business card.

    Need an abstract configuration file for more complicated setups?

    • Use .ncl. Nickle allows you to define functions so that you can generate/compute the correct configuration by changing a few variables/flags.
  • Skyzyx@lemmy.worldEnglish
    1·
    2 years ago

    Whatever. Comments are helpful, which makes pure JSON a poor choice. JSON5 or JSON-C are better, but linting and static analysis are important to every form of code, so make sure that what you use for that will understand your syntax.

    My current preference is generally TOML, but I’ve started dabbling with custom HCL2 DSLs. (I write a lot of Go and Terraform.)