preserving comments

[wmtorode]

Is there a way to preserve comments so that if I edit a file the comments it contained are still there?

[dpranke]

Unfortunately, no, not currently.

In order to do that you need to preserve the whole parse tree, which certainly doesn't work inside the existing simple load/dump API.

I would like to support this, though, it's something of a challenging problem. I've never seen an API for doing something like that and so it's a bit unclear what a good API would look like.

[wmtorode]

Thanks, I figured that would be the answer. It would be great if this could be supported even if it's through a different API than the current load and dump.

[dpranke]

Agreed. (Sorry for not responding sooner. I'm still mulling over what an API like this might look like.)

[qneill]

This npm package is doing it (or claiming to): https://www.npmjs.com/package/comment-json

[dpranke]

@qneill Thanks for the pointer. I'm looking at that now, and it does seem to be at least reasonable well-worked out.

[Alphadelta14]

Some other parsers with round-trip support include ruamel.yaml for YAML (yes, it is actively developed on sourceforge in 2025) and tomlkit for toml.
Both use some variation of dict subtypes (CommentedMap in ruamel.yaml and Container in tomlkit) which store comments (and tomlkit also stores whitespace absolutely) relative to their closest content.
For adding new comments, ruamel.yaml adds a bunch of methods to its CommentBase Mixin like yaml_set_start_comment. tomlkit also adds a few extra methods to its Container but mostly wraps its content as dedicated objects which support comments.

I may be interested in picking this up if I start adopting JSON5 in private projects more seriously.

[dpranke]

Thanks for the links! Wow, has it really been 5 years since I've commented on this? That's kinda sad ...

I was actually working on this earlier this year and made a good deal of progress before I got distracted by something else. I'll take a look at the things you're pointing at (and comment-json again) and see how they compare to what I had in mind.

Tangentially, unless you had a specific reason to use JSON5 for a project (like existing JSON5 files, or something strictly compatible with JavaScript), I probably wouldn't. There are other similar formats that are more popular and more powerful. YAML is the obvious frontrunner, but if you wanted something a lot lot simpler, I would probably point you at HJSON. I actually have a different format that is very similar to HJSON but has some things I consider advantages, but it's not particular public or suited for consumption by others at this point, so I won't point you at it.