4 ms·

It doesn’t improve the dev experience if the compilers don’t produce it, and this is really about dev comfort. You need to be able to modify JSON programaticall

It doesn’t improve the dev experience if the compilers don’t produce it, and this is really about dev comfort. You need to be able to modify JSON programatically and keep the comments, if the output is pretty-printed. Also, NaN numbers are an entire features, which they talk about above.

wruza 6y ago
But why should re-jsoning keep //-comments? I never met the need for that personally. Comments help initial filename.json to be parsed by human eyes, and when it is sucked into a program (and possibly transformed), they lose meaning, even when pretty printed. For them to stay, one can put comments into real keys and/or structure their data appropriately. Even if one ultimately needs to keep json document’s human structure (like key order, comments, whitespace nuances), they may create and use more syntax structure-aware library to do that.
- laurent92 6y ago
  > they may use more structure-aware library to do that Sure. I’m particularly thinking about mvn upgrades or “npm update”, which modify pom.xml/package.json files to upgrade the libraries, after checking rules (non-breaking changes or not, vulnerabilities or latest, etc). For mvn, libraries never succeeded to modify the pom in-place without wrecking the file format, so mvn upgrades never became a thing. It’s also a demonstration that a DOM with comments in memory doesn’t ensure we can output the file as-is ;)
  - crazygringo 6y ago
    That sounds like an entirely separate issue from what JWCC tries to achieve though. For programatically upgrading JSON config files, it's not just comments but whitespace, indentation, etc. that need to be preserved. Honestly that needs an entirely separate tool/library from normal JSON encoding and decoding -- e.g. special jwcc_insert() and jwcc_delete() functions that guarantee the file remains untouched (exact formatting preserved) except for the modified part. It's really more akin to when your apache.conf file gets modified programatically -- everything is preserved exactly except for the specific lines that get touched/added.

wruza 6y ago

But why should re-jsoning keep //-comments? I never met the need for that personally. Comments help initial filename.json to be parsed by human eyes, and when it is sucked into a program (and possibly transformed), they lose meaning, even when pretty printed. For them to stay, one can put comments into real keys and/or structure their data appropriately. Even if one ultimately needs to keep json document’s human structure (like key order, comments, whitespace nuances), they may create and use more syntax structure-aware library to do that.

laurent92 6y ago
> they may use more structure-aware library to do that Sure. I’m particularly thinking about mvn upgrades or “npm update”, which modify pom.xml/package.json files to upgrade the libraries, after checking rules (non-breaking changes or not, vulnerabilities or latest, etc). For mvn, libraries never succeeded to modify the pom in-place without wrecking the file format, so mvn upgrades never became a thing. It’s also a demonstration that a DOM with comments in memory doesn’t ensure we can output the file as-is ;)
- crazygringo 6y ago
  That sounds like an entirely separate issue from what JWCC tries to achieve though. For programatically upgrading JSON config files, it's not just comments but whitespace, indentation, etc. that need to be preserved. Honestly that needs an entirely separate tool/library from normal JSON encoding and decoding -- e.g. special jwcc_insert() and jwcc_delete() functions that guarantee the file remains untouched (exact formatting preserved) except for the modified part. It's really more akin to when your apache.conf file gets modified programatically -- everything is preserved exactly except for the specific lines that get touched/added.