undefined | Better HN

0 pointsbenatkin14y ago0 comments

That's npm, not node itself, that relies on package.json. When its creator chose it, he knew exactly what JSON is. He's maintained on HN and elsewhere that he made a good decision. So even if you stop calling this JSON, he's not buying it.

The package.json files, by and large, don't have a multiline string problem. For trailing and missing commas, I think you could make something that automatically fixes them, if that's the only problem, and run it before npm is run, perhaps using a shell alias.

0 comments

3 comments · 2 top-level

aseemk14y ago· 1 in thread

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.

ZenPsycho14y ago

  { 
    "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"]
  }

  {
    "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"
    ]
  }

mvanveen14y ago

  That's npm, not node itself, that relies on package.json.  When its creator chose it, 
  he knew exactly what JSON is.  He's maintained on HN and elsewhere that he made a good
  decision.  So even if you stop calling this JSON, he's not buying it.

Going along with this, there are other formats that lend themselves extremely nicely to being human readable/writable/parsable. I've seen YAML (http://en.wikipedia.org/wiki/YAML) used out in the wild to support these sorts of use cases, often in systems which also leverage JSON.

Edit: Not saying the author of npm is wrong for picking JSON, just that there already viable serialization alternatives expressly designed with human factors in mind.

j / k navigate · click thread line to collapse