You seem to be implying that making an effort to seek change in the format that npm uses is a bad idea. I'm not sure I understand why that is. Surely the status quo isn't always perfect?
In the software world in general, and in Node/npm land especially, code talks. I thought it'd be more productive to build and share a working ES5-style JSON parser than to simply ask Isaac if npm would support ES5-style JSON. =)
Yes, you're right about trailing commas. One motivation that such an approach couldn't address is documentation: I've frequently wanted comments in my package.json files, e.g. explaining a particular dependency version, or a script command.
{
"name": "My fancy package",
"comment": "I include both versions here for compatibility with package x",
"scripts": ["script1.js","script2.js"],
"comment":"to run the build script",
"comment":"cd to the bin directory and type:",
"comment":"node build.js",
"build": ["bin/build.js"]
}
or
{
"name": "My fancy package",
"--": [
"I include both versions here for compatibility with package x",
"to run the build script",
"cd to the bin directory and type:",
"node build.js"
],
"scripts": [
"script1.js",
"script2.js"
],
"build": [
"bin/build.js"
]
}
In the software world in general, and in Node/npm land especially, code talks. I thought it'd be more productive to build and share a working ES5-style JSON parser than to simply ask Isaac if npm would support ES5-style JSON. =)
Yes, you're right about trailing commas. One motivation that such an approach couldn't address is documentation: I've frequently wanted comments in my package.json files, e.g. explaining a particular dependency version, or a script command.