5.0.0

MAJOR: blank lines are now modeled explicitly instead of being inferred from loc and historical line-break logic.

• Introduce explicit BlankLine comment tokens and use them during parse() / stringify().
• Add parse(code, reviver, { no_comments, no_blank_lines }).
• Add removeBlankLines() for removing blank lines globally or at a specific comment location.
• Improve round-trip behavior for JSON files that rely on preserved blank lines, including a Bun-derived regression fixture.
• Update TypeScript definitions and documentation for the new blank-line model.

Potential breaking changes

This release may introduce breaking changes for consumers who directly inspect or mutate comment tokens:

• CommentToken is now a union type. A token may be { type: 'BlankLine', inline: false }, so value and loc are no longer guaranteed on every token.
• stringify() no longer uses loc or the old internal blank-line history to infer empty lines. Blank lines are rendered only from explicit BlankLine tokens.
• Custom logic that manually creates or rewrites comment token arrays may need to be updated to preserve blank lines correctly.

Behavior differences

If your existing usage includes business logic related to blank lines, you may notice behavior differences:

• Code that previously relied on loc-based blank-line rendering may now produce different output unless it preserves BlankLine tokens explicitly.
• Code that assumed every comment token was a line/block comment may need an extra type check for BlankLine.
• Parsing with { no_blank_lines: true } now provides an explicit way to drop blank lines, while default parsing preserves them as first-class tokens.

An upgrade review is recommended for dependents that have custom comment-token processing or formatting logic around blank lines.

4.5.0

• MINOR: the new moveComments and removeComments to help you to manipulate comments
• Improve typescript definitions
• Fixes README.md

An upgrade is recommended for all dependents

4.4.1

• MINOR: #39, implemented the tc39 proposal of https://github.com/tc39/proposal-json-parse-with-source (only the context.source), so that it is possible to handle BigInts.

const {parse, stringify} = require('comment-json')

const parsed = parse(
  `{"foo": 9007199254740993}`,
  // The reviver function now has a 3rd param that contains the string source.
  (key, value, {source}) =>
    /^[0-9]+$/.test(source) ? BigInt(source) : value
)

console.log(parsed)
// {
//   "foo": 9007199254740993n
// }

stringify(parsed, (key, val) =>
  typeof value === 'bigint'
    // Pay attention that
    //   JSON.rawJSON is supported in node >= 21
    ? JSON.rawJSON(String(val))
    : value
)
// {"foo":9007199254740993}

An upgrade is recommended for all users.

4.2.2

• MINOR: #33, symbol support for typescript definitions. Since new version of typescript eventually supports symbol object properties, this update uses symbol type instead of any for comment properties

An upgrade is recommended for all users.

4.1.0

• MINOR: #19, CommentArray::sort will now maintain comments
• PATCH: fixes #27

An upgrade is recommended for all users.

MAJOR 4.0.0, 2020-09-01

• MAJOR: fixes #21, removes after-comma:${prop} and after symbol properties, and introduce after:${prop}
• MAJOR: #20 symbol properties of comments are now not enumerable, so that you could use Object.keys to get the keys of the parsed object as the normal ones

4.0.0 brings breaking changes, but however, logically but not programmatically.

So for most scenarios, you need NOT to change your code, and an upgrade is recommended.

Upgrade Guide

Use assign instead of object spreading

const parsed = parse(`{
  // comment
  "foo": "bar"
}`)

In 3.x, it is ok to do as following

stringify({...parsed}, null, 2)
// {
//   // comment
//   "foo": "bar"
// }

But with comment-json@4.0.0, the code above will print

{
  "foo": "bar"
}

Because since 4.0.0, symbol properties of comments are non-enumerable, so object spreading will not work for this case, and you should use assign function to copy those properties.

const {assign} = require('comment-json')

stringify(assign({}, parsed), null, 2)

Changes of symbol properties

TL;NR

{
  "foo": "bar" /* after value */, // after foo
  "bar": "baz" // after bar
}

In 3.x

• The comment after foo is marked as Symbol.for('after-comma:foo')
• The comment after bar is marked as Symbol.for('after-value:bar')

But in 4.x

• The comment after foo is marked as Symbol.for('after:foo')
• The comment after bar is marked as Symbol.for('after:bar')

And in both 3.x and 4.x after value is marked as Symbol.for('after-value:foo')

3.0.0

In 2.x, inline comments after comma(,) are not belong to the current prop, see #17

const {parse, stringify, assign} = require('comment-json')

// Just insert a new property `baz` into the parsed object and return a new object
// TL;NR
const insert_baz = (origin, value) => {
  const obj = {}
  assign(obj, origin, ['foo'])
  obj.baz = value
  assign(obj, origin, ['bar'])
  return obj 
}

// 2.x
const parsed = parse(`{
  "foo": "foo", // foo
  "bar": "bar"
}`)

const obj = insert_baz(parsed, 'baz')
console.log(stringify(obj, null, 2))

// {
//  "foo": "foo",
//   "baz": "baz", // foo
//   "bar": "bar"
// }

Because, in 2.x, inline comment ' foo' is a before:bar comment token of property bar.

And, in the new MAJOR version 3.0.0, we introduce a new comment token type after-comma:${prop} to fix this issue.

If the code above is executed with comment-json 3.0.0, the result will be

{
  "foo": "foo", // foo
  "baz": "baz",
  "bar": "bar"
}

3.0.0 brings a breaking change, but however, logically but not programmatically.

So for most scenarios, you need not to change your code.

2.2.0

• FEATURE: Support trailing commas for objects and arrays ( #8 )

parse(`{
  // comment
  foo: 'bar',
}`)

2.1.0

2.1.0

• FEATURE: Introduce the CommentArray to auto deal with comments when modified. See here for details

2.0.9

2.0.9

This major version fixes several issues and provides new features:

• supports comments everywhere, yes, EVERYWHERE in a JSON file, eventually 😆
• fixes comments in arrays, #7 #9

Breaking changes vs 1.x

The new version uses Symbols to store comments so that they will never conflict with normal JSON property fields, so the structure of the return value of method parse() changes.

For details, see the document