Just found a relevant quote from Crockford on the subject: I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. Source: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr I don't agree with his reasoning there at all, but there you have it. On Saturday, January 5, 2013 1:22:06 PM UTC-5, Alex Kocharin wrote: > > Hello, everybody. > > > TL;DR: I think that JSON is not a suitable config file format, and I want > npm to be able to read configs stored in some other way by default. It > might be just javascript, or yaml, I don't really care as long as it better > for configuration files than json. > > > So, there is a dependency list in package.json, and it would be a good > practice to have a comment for every line describing why we require that > package, why we require that version of that package, what known problems > we have and so on. > > But there's a small issue. JSON format doesn't allow comments in any way. > > Right now there are a couple of different ways around it of course: > > 1. Non-standard JSON entries like "@comment": "blablabla". Unfortunately, > javascript editors doesn't highlight it as a comment, and it's just plain > ugly. Also this violates strict javascript mode, so God knows what trouble > it'll cause in the future. > 2. Keep a commented dependency list in a separate file. This violates DRY > principle, so we could update one file and forget to update another. The > same goes for /**package **/ hack I believe. > 3. Use some kind of build system. Just for damn comments in one file? > > Also, there's another wrong thing with JSON, it's too strict. You can't > omit double quotes from keys, you can't leave a trailing comma, etc. JSON > is human-readable, but it's just not damn human-writable. > > Well... I went for 3rd option for a very long time. We used package.js > file and a Makefile that compile js to json. Yes, that's three damn files > instead of one. That's an example of our package.js file. > https://gist.github.com/4462764 . But a number of supported packages > grew, and compiling this slowly became a major pain in the ass. I recently > got an issue when I updated package.js, but forgot to compile it, and > debugging this one was a quite interesting experience. So, I'm now in a > mood of forking things and making all my public packages incompatible with > mainstream npm... > > > So, there's a couple of alternatives. For example, Travis use YAML, and > there is CSON (it's coffeescript version with blackjack and hookers). > > And I think there was a couple of discussions about it. So, did anybody > come up with more or less sane idea how to deal with this? What happened to > package.json.js? > > > Happy New Year! > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
