modify(): trailing inline comment is re-attached to the newly inserted property

[italopaesano]

Summary

When a new property is appended with modify(), a same-line (inline) trailing comment on the object's last property is re-attached to the newly inserted property. The comment then documents a different key, so the edit changes the meaning of the file, not just its formatting.

Environment

• jsonc-parser: 3.3.1 Also reproduces on 4.0.0-next.2 see the first comment with updated attachment
• node: v22
• Reproducible on any OS (pure string manipulation, no I/O involved).

Steps to reproduce

import { modify, applyEdits } from 'jsonc-parser';

const input = `{
  "host": "localhost",
  "port": 8080 // default port
}`;

const edits = modify(input, ['debug'], true, {
  formattingOptions: { tabSize: 2, insertSpaces: true }
});

console.log(applyEdits(input, edits));

(The behavior is identical whether the package is loaded via import or require.)

Actual behavior

{
  "host": "localhost",
  "port": 8080,
  "debug": true // default port
}

The // default port comment clearly belongs to port, but it is now attached to debug: true, where it makes no sense.

Expected behavior

{
  "host": "localhost",
  "port": 8080, // default port
  "debug": true
}

The comment should stay with port, and the new property should be inserted after it.

Scope

Triggers when: the last property of an object has an inline (same-line) trailing comment and a new property is appended.

Does NOT trigger when:

• the comment is on its own line, or
• the inline comment is on a non-last property.

So only the inline comment of the last property is affected.

Likely cause

The insertion point appears to be computed immediately after the last property's value token. The original trailing comma and the inline comment that follow it are left in place, so the inserted text lands before them — which visually re-associates the comment with the newly inserted property.

Related issues

• Option to keep spaces before inline comments #76 — Option to keep spaces before inline comments: same area (inline comments handled by modify), but that report is about lost spacing/alignment, whereas this is about the comment being moved onto the wrong key (a semantic change).
• getNodePath/modify do not work for property nodes (capture too much content) #51 — modify ... capture too much content: also about modify affecting content beyond the targeted node.

This seems distinct enough from #76 to warrant its own issue, but I'm happy to consolidate if you prefer.

jsoncbugdemo.zip

[italopaesano]

Follow-up: the same underlying cause also affects deletion (removeProperty, i.e. modify(text, path, undefined, ...)), and there it can be worse — deleting one property can silently drop the trailing comment of a neighbouring property.

Environment — jsonc-parser: 3.3.1 · node: v22 Also reproduces on 4.0.0-next.2

Reproduction

import { modify, applyEdits } from 'jsonc-parser';

const input = `{
  "a": 1, // keep me
  "b": 2
}`;

const edits = modify(input, ['b'], undefined, {   // undefined = delete
  formattingOptions: { tabSize: 2, insertSpaces: true }
});

console.log(applyEdits(input, edits));

Actual output

{
  "a": 1
}

The // keep me comment belonged to a, a property that was not touched, yet deleting b removed it.

Expected output

{
  "a": 1 // keep me
}

Why

Same root cause as the insertion case: the deletion range starts at previous.offset + previous.length (the end of the previous property's value), which is before that property's trailing comment — comments are trivia and live outside the property node, so the comment falls inside the removed range.

Related variant

When the deleted property is the one carrying the comment, the comment instead survives as an orphan on the previous property:

// input
{
  "a": 1,
  "b": 2 // bye
}

// after deleting "b"
{
  "a": 1 // bye
}

Also reproduces on the 4.0.0 pre-release

Both behaviours — the insertion from the original report and the deletion above — also reproduce on the current pre-release (jsonc-parser@next, 4.0.0-next.2), so this is not specific to 3.3.1:

// after inserting "debug": the comment moves onto the inserted property
{
  "host": "localhost",
  "port": 8080,
  "debug": true // default port
}

// after deleting "b": the "// keep me" comment of "a" is gone
{
  "a": 1
}

So the trailing-comment handling problem spans both insertion and deletion; a complete fix should cover removeProperty as well.

jsonccommentdemo.zip