I introduce new human and computer friendly and easy to extension format. It name is "Tree" https://github.com/nin-jin/node-jin#tree This is only experiment, not for production yet!
Features: 1. streaming (dislike XML and JSON than needed root node): parsed line-by-line 2. simple (XML, YAML, JSON is more complex): only struct- and value- nodes. 3. no escaping (no backslashes, no ampersand-encoding, no symbol repeating): may content binary data as set of lines 4. fast (because 2 and 3): js-implementation is 15x faster than yaml-js. but slower than native json implementation of course. 5. extendable (some changes of scheme in XML, JSON etc are not back compatible): As example, let us write package.tree: ========================================= name =jin version =1.2.0 description =Harmoy node.js sugar full-async framework homepage =https://github.com/nin-jin/node-jin author name =Nin Jin email [email protected] keywords =javascript =framework =modules dependencies fibers =* npm =* engine = node >= 0.4.1 readme =This is long =multiline text ========================================= Then we need to extend scheme to allow comments for each dependencies: ========================================= dependencies fibers =* //= for synchronization of async tasks npm =* //= for installation modules on demand ========================================= Or: ========================================= dependencies fibers =* reason =Synchronization of async tasks npm =* reason =Installation modules on demand ========================================= And this do not break back-compatibility! In XML or JSON it will be broken :( Let us create package.json from any of 3 given above package.tree ========================================= require( 'jin' )( function( $ ){ var pack= $.jin.tree([ $.fs.readFileSync( 'package.tree' ) ]).parse() var json= { name: pack.select(' name / ').toString() , version: pack.select(' version / ').toString() , description: pack.select(' description / ').toString() , homepage: pack.select(' homepage / ').toString() , author: { name: pack.select(' author / name / ').toString() , email: pack.select(' author / email / ').toString() } , keywords: pack.select(' keywords / ').values() , bugs: { email: pack.select(' bugs / email / ').toString() } , dependencies: new function( ){ pack.select(' dependencies / ') .forEach( function( dep ){ this[ dep.name ]= dep.toString() }.bind( this ) ) } , engine: pack.select(' engine / ').toString() , readme: pack.select(' readme / ').toString() } $.fs.writeFileSync( 'package.json', JSON.stringify( json ) ) } ) ========================================= суббота, 5 января 2013 г., 22:22:06 UTC+4 пользователь Alex Kocharin написал: > > 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
