Not sure why it doesn't show the build status in this PR.

Anyway, here it is:

I'm a big fan of YAML. Being able to add comments, and cleaner syntax is huge. I understand there are some gotchas, but it's so prevalent now, that you learn them pretty quick.

That said, I'm not against adding this support. I think it's a small enough change, and I understand everyone doesn't share my appreciation for YAML.

I really miss the the ability to add comments :)

However, our environment is heavily biased towards Node and being able to operate on JSON files is much more convenient that YAML files.

I'm pretty confident that YAML/JSON won't result in a bifurcation of your code (which is the biggest risk from adding support for a secondary input format). I think this code converts to a Python structure early enough that your code will be safe.

Updates made and build is passing

Interesting. I can see an argument for supporting JSON in that it makes it easier to generate configuration files, but then I'm not sure if that's something we want to encourage. (What's your use case, and would it be equally well served by an import mechanism and/or parameterisation of configuration values?)

Thanks for the contribution - I need to think about it some more.

I'm +1 on having JSON as an alternative format. I fully understand the advantage of YAML (comments and cleaner, more human readable). JSON is natively supported by just about any language, so for automated generation and/or editing of a Fig-stack definition, I think this is a big win.

I'm not sure if that's something we want to encourage.

All examples in the documentation can keep using YAML, to emphasise it's the "standard" format. An extra section / note "alternative formats" can be added to show that JSON is also supported.

JSON is a subset of YAML so this should already work out of the box with the current YAML parser.

Parsing the file is actually the smallest part of this change.
Also, since invalid JSON files can be valid YAML files and valid JSON files with duplicate IDs are not valid JSON files, I think using a YAML parser on JSON could cause confusion down the line with no added benefit.

👍 for JSON configs for reasons like this:

Note: When mapping ports in the HOST:CONTAINER format, you may experience 
erroneous results when using a container port lower than 60, because YAML will 
parse numbers in the format xx:yy as sexagesimal (base 60). For this reason, we 
recommend always explicitly specifying your port mappings as strings.

Since the Yaml parser supports JSON documents I'm reluctant to make any code changes here. It might be worth mentioning in the docs that you can use JSON, it's just "not considered a supported feature, even thought it should work in most cases".

This will be documented in #2291