--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
It can often be a good idea to add comments for yourself and others around your dependencies, especially on a large project.
Hi Dick,I explained that in an initial message. Well... it won't hurt to repeat though.1. This is not highlighted by editors properly2. This is too long, dozen characters instead of two or three
3. No multiline comments
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.
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.
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
--
Hi Trevor,I'm talking about package configuration, not build configuration. gyp has absolutely nothing to do with it.
.Developers' responses to specific questions/suggestions with "Why do you want to do that? It sounds like you're making bad decisions." is a cliche that still happens all the time, and annoys the heck out of me.
--
Not much of a "discussion" per se, but more like something that most
eventually come to realize, but only *after* doing it the wrong way
first.
It'd be better to only support node-gyp for building packages, and get
rid of scripts.install altogether.
Thanks. This makes sense for compiling, however I had been using the install key for compiling coffee-script and minimizing resources when my application deployed to Heroku.I realize it is not a great solution, but the default node.js buildpack calls `npm install` and then just starts.
Transpiling and minification are better handled by a prepublish script anyway: https://npmjs.org/doc/scripts.html That way, the module doesn't need to depend on CoffeeScript just to install and deployment will happen that much faster.
--
That's why prepublish scripts get run on `npm install` :)
Isaac,
That's great, I use"//" in other places but always assumed they would get iterated in package.json dependencies. So we can safely do this?
{ "dependencies" :
{ "foo" : "1.0.0 - 2.9999.9999"
, "//" : " comment about baz"
, "baz" : ">1.0.2 <=2.3.4"
, "//": " comment about boo"
, "boo" : "2.0.1"
}
}
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.
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.
--
JSON isn't the friendliest to write. Keys need to be quoted, objects and arrays can't have trailing commas, and comments aren't allowed — even though none of these are the case with regular JavaScript today.
That was fine when JSON's goal was to be a great data format, but JSON's usage has expanded beyondmachines. JSON is now used for writing configs, manifests, even tests — all by humans.
There are other formats that are human-friendlier, like YAML, but changing from JSON to a completely different format is undesirable in many cases. JSON5’s aim is to remain close to JSON and JavaScript.
JSON5 remains a strict subset of JavaScript, adds no new data types, and works with all existing JSON content.
Sorry for resurrecting an old thread, but have you considered using JSON5 (https://github.com/aseemk/json5)?Author's rationale:
Sorry for resurrecting an old thread, but have you considered using JSON5 (https://github.com/aseemk/json5)?Author's rationale:
Nothing to be sorry about, the issue still exists, and there is no widely accepted solution in the community.
Yes, json5 will solve this nicely if it was accepted as a possible package info format in npm packages. But it doesn't seem to be happening soon.
Personally, I solved it using yaml language (and package.yaml files in a project), and yapm module (https://github.com/rlidwka/yapm), it's a wrapper around npm to convert it to json format on the fly.
On Wednesday, October 2, 2013 12:02:08 PM UTC+4, Dmitry Pashkevich wrote:JSON isn't the friendliest to write. Keys need to be quoted, objects and arrays can't have trailing commas, and comments aren't allowed — even though none of these are the case with regular JavaScript today.
That was fine when JSON's goal was to be a great data format, but JSON's usage has expanded beyondmachines. JSON is now used for writing configs, manifests, even tests — all by humans.
There are other formats that are human-friendlier, like YAML, but changing from JSON to a completely different format is undesirable in many cases. JSON5’s aim is to remain close to JSON and JavaScript.
All this while:JSON5 remains a strict subset of JavaScript, adds no new data types, and works with all existing JSON content.
On Saturday, January 5, 2013 10:22:06 PM UTC+4, 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 debu
--
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
But it doesn't seem to be happening soon.
El miércoles, 2 de octubre de 2013 23:20:29 UTC+2, Alex Kocharin escribió:But it doesn't seem to be happening soon.
Never. Extremly slow compared with native json parser.
I also agree with the OP. The json format is being misused massively by the people. JSON is a transport protocol, it was never intended to be used as a storage format. Double quotes, no comments, impossible to maintain by humans.
--
--
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/NmL7jdeuw0M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.
...