> I really don't think you'd need comments in the package file, but that's not why we picked JSON.
What's the harm in letting me decide whether to add comments? Also it's the first place users often look; why not allow me to add useful information? Also, comments have been a big part of programming for decades, and not allowing them without a suitable replacement for annotations is a big step backwards.
> JSON was nice and easy because it's provided natively by PHP, unlike Yaml. Also we were inspired quite a bit by NPM, and I guess that played a role, implicitly.
Yaml can be done in pure PHP so it should not be hard to embed a YAML parser, and I think it would be worth it, to provide something that programmers have taken for granted for decades. Also yes NPM is successful but that doesn't justify copying bad design decisions from it.
> Also, it is a fact that every format has haters, and we couldn't have picked something that makes everyone happy. So we picked one, and I'm sure people will be able to live with it.
This one's easy. Ignore the haters.
> Now I do recognize the fact that some people may not be used to JSON (though I find it quite awkward - even narrow-minded - for web devs), and for that reason I added some syntax checks to warn users of common mistakes in their JSON file, because while PHP has native support, all the info you get from it for malformed JSON is a null return value and "Syntax error" in json_last_error(). We also plan to have an init command that will allow you to build a package file interactively.
With JSON you get experience from it but still trip over it all of the time. Libraries choke on trailing commas, as well they should, because it's a serialization format, not an editing format! Using JSON as an editing format is wrong. Here's a pull request I sent about a trailing comma issue that prevents a repo with 176 watchers from working. https://github.com/atmos/smeagol/pull/15/files
...but you're not creating a new a bad design decision, you're copying a bad design decision, that was copied from somewhere else. And I commend you for coming up with this, as I think the pros outweigh the cons.
OK, one of the first places users often look. It contains information that's not commonly found in the README, such as dependencies. And I often add comments to dependencies when working with Ruby On Rails, which fortunately uses ruby for its dependency file.
Yes. Dependency information and script commands are there. Both ought to be able to have comments. Node.js has the ability to load JavaScript, and since it's an installed environment, YAML isn't too much overhead. Both support comments. It can be serialized to JSON if needed.
It can be used more appropriately as a serialization and storage format with npm. It would be a matter of having a script for pushing a package that generates a package.json file from javascript or YAML, and adding it to .gitignore (but not .npmignore) so people see the file with comments enabled.
What's the harm in letting me decide whether to add comments? Also it's the first place users often look; why not allow me to add useful information? Also, comments have been a big part of programming for decades, and not allowing them without a suitable replacement for annotations is a big step backwards.
> JSON was nice and easy because it's provided natively by PHP, unlike Yaml. Also we were inspired quite a bit by NPM, and I guess that played a role, implicitly.
Yaml can be done in pure PHP so it should not be hard to embed a YAML parser, and I think it would be worth it, to provide something that programmers have taken for granted for decades. Also yes NPM is successful but that doesn't justify copying bad design decisions from it.
> Also, it is a fact that every format has haters, and we couldn't have picked something that makes everyone happy. So we picked one, and I'm sure people will be able to live with it.
This one's easy. Ignore the haters.
> Now I do recognize the fact that some people may not be used to JSON (though I find it quite awkward - even narrow-minded - for web devs), and for that reason I added some syntax checks to warn users of common mistakes in their JSON file, because while PHP has native support, all the info you get from it for malformed JSON is a null return value and "Syntax error" in json_last_error(). We also plan to have an init command that will allow you to build a package file interactively.
With JSON you get experience from it but still trip over it all of the time. Libraries choke on trailing commas, as well they should, because it's a serialization format, not an editing format! Using JSON as an editing format is wrong. Here's a pull request I sent about a trailing comma issue that prevents a repo with 176 watchers from working. https://github.com/atmos/smeagol/pull/15/files
...but you're not creating a new a bad design decision, you're copying a bad design decision, that was copied from somewhere else. And I commend you for coming up with this, as I think the pros outweigh the cons.