I really wish people wouldn't use JSON for configuration. The lack of comments and shortcomings in formatting abilities make it particularly ill-suited. { "_comment": "this is a comment" } is cringeworthy to. It's great for transport, but horrible for static file config.
YAML is good, but not to everyone's taste. I've been using it for a long time (as a ruby developer) but many people I know find it ugly.
I think Arc config looks much better than anything they could have come up with using JSON/YAML. Optimize configuration files for humans, not machines. If its simple enough to learn and be readable, more power to em.
It's interesting. can you have @js more than once? can you have @app more than once? pretty sure ಠ-ಠ is a valid app name, but ಠ_ಠ isn't.
i also can't quite tell how to say map of maps. i'd guess it's
@this-section-has-a-map
hello-world
name child-map
ಠ-ಠ a
ಠ_ಠ b
but it's hard to tell.
Also, i'm not exactly a fan of { "_comment": "this is a comment" }, but i've run into several situations with yaml where i want to build a tool to rewrite a bunch at once, but since comments have no representation in the parse tree i have to do goofy vim macros to do my edits. since _comment is in the tree, i can add more keys without trashing the existing comments.
Hey, one of the .arc authors and maintainers here.
Only one of each section is what we designed for though the validations for that might be broken (and if so we can fix right away). Nesting is limited to one level. No need for more that we've seen yet.
I'm a proponent for JSON but agree that the lack of comments are one of the more annoying things I frequently run into.
edit--Especially when it comes to users editing config files. Imagine a new user trying to edit a web server/db/.bashrc file that didn't have comments to help out?
Rather than inline-comments I've always had separate documentation. This helps prevent trying to cram all the edge case caveats and everything into the configuration file.
inline comments are handy for pointing out "non standard" configuration settings for your enviroment. especially on production systems.
It aids in troubleshooting greatly to have inline comments point out "odd" settings in configuration without having to look at seperate (usually old) documentation.
Then use json5. Super weak excuse. Or use yaml or some other format and pipe it into some to-json converter.
Also, json has json schema which tools like VS Code support. They can autocomplete your config. Pretty promising over most other tooling.
But coming up with your own config has pretty much all the downsides. Yeah, you can invent some cuter syntax. But now your users can't even get syntax highlighting in their editor. Awful UX.
JSON5's support for unquoted keys seems like a misfeature. Not to mention that (by its nature) it has the same (lack of) support burden as any other new configuration format. If you're going to go through that frustration and incompatibility, why not pick something better suited to the job?
https://serverless.com/ - uses yaml or JSON or js. This looks like an opportunity for the community to grow some more which is almost always a benefit. A new filetype isn't always the best, but it CAN be useful in some contexts, I haven't vetted if this is the right one.
Yup, serverless works quite well. have used it myself.
Albeit, I'm not fully sold on this whole fake-serverless architecture.
A major part of it is that AWS is arguably frustrating, since the docs are __clearly__ written by marketing people, not engineers. Every aspect feels non-dev friendly.
I would love to see something like Captain Duck Duck, so you can host your own serverless platfrom, sort-of a personalized AWS?
I don’t think you get my gist about syntax vs information. I can express the same data in a different format, in the same way that JSON and YAML can often be transformed into each other.
You are pulling a straw man by implying that requires much cloudformation, which is completely unrelated. Besides, CF is a good example of how you can use two different syntax to describe the same information.
The format of a configuration file has no relation to the output of the program that parses it. Why are you being so obtuse about this? Your three-line arc file would be a three line YAML file. Stop doubling down on this nonsense.
