Closed hatashiro closed 7 years ago
I've never been a big fan of YAML, but I'm not necessarily opposed to switching before the next major version. Can you summarize the benefits?
Yes, the benefits are basically what's better of YAML over JSON. JSON is designed to be a data serialization format, not to be a generalized config format. For example,
Many of tools like Travis CI, Circle CI, ESLint, hpack, etc support YAML as their config. Surely, adopting YAML doesn't mean dropping JSON. We can support both of them, and let users choose which one to use.
I was originally in favour of this and I think there is a discussion somewhere on a github repo although I have just searched and failed to find it. However I'm not such a huge fan of YAML, since even though it can be much nicer to edit by hand, it is an absolute nightmare to implement. I certainly wouldn't agree that the syntax is simpler from an implementation perspective.
At this stage I'm tempted to say that this ship has sailed, especially in the JS world, and we should just accept that JSON has won as a file format for these sorts of files.
I agree that YAML spec is huge and it's nearly impossible to implement a complete YAML parser very quickly. I was thinking of implementing this with the yaml package which internally uses LibYAML. From our perspective, the implementation should be easy as the yaml package provides the same interface (FromJSON
and ToJSON
) as Aeson does.
I would not totally agree that JSON has won in the JS world, because most of tools just support both (the only exceptions are npm and bower).
I am also not a huge fan of YAML, and I may prefer simpler formats such as TOML, but users may find it easy to use YAML as it's commonly used as an alternative of JSON. Surely, the current config is simple enough to stick to JSON, so I'd like to hear your ideas about supporting config formats other than JSON.
YAML is in some sense designed to allow arbitrary code execution, which means that if we decide to support YAML, any tool working with these files, i.e. not just psc-package, needs to be very careful to use the safe subset (which is often not the default option provided by YAML libraries). I'm worried that people creating tools which interface with these files could easily make them vulnerable to remote code execution exploits by accident.
See for example this vulnerability which has since been addressed. I would argue that it is still easy to accidentally introduce vulnerabilities while using this library though, as the unsafe variant is still the default. See also this blog post, in particular:
For the most part, you never want to accept YAML from the outside world. The risks are too high, [...]
I'm afraid I overlooked the vulnerability, although I have once read. I now agree that adopting YAML is not an easy decision. How do you think of other formats like TOML? I personally like if I have other option than JSON, but also understand starting to support other formats can result in config kitchen sink, like webpack supporting dozens of config languages.
TOML does look sensible to me and I am happy to see it catching on in the Rust world. I was originally thinking that since purescript users will in most cases be dealing with JSON config because of npm anyway, it makes most sense to stick with that, but on second thoughts I don't think that is a particularly strong argument.
I think I'd prefer TOML to JSON as a file format for psc-package. Whatever we end up going for, I think we should choose one and only one out of JSON and TOML.
By the way, I found the original discussion :D https://github.com/purescript/purescript/pull/2337
I guess now it's the matter of whether using TOML or sticking to JSON. JSON has no problem for the time being, but if we consider moving, I think it's the right time.
If it aint broke...
I haven't had any issues with JSON so far.
Hmm, I guess we may close this. YAML has its shortage, and it seems there's no strong reason to adopt other formats.
Thanks for sharing your ideas.
This maybe somewhat big change, but how about using YAML as psc-package file format,
psc-package.yaml
? YAML provides some merits such as comment and flexible syntax.I guess this don't need to be so breaking, if we leave JSON parser for backward compatibility and just create YAML for new projects. Surely it can just be dropped.