First reported by @antico5

On Rust, our types do have [serde] attributes for serialization. But on TS side, the types are properties that cannot be JSON.stringify()ied or visualized easily. One workaround is to do:

console.log(
  util.inspect(parseTree, {
    getters: true,
    showHidden: true,
    showProxy: true,
    depth: Infinity,
  })
);

Which produces something like:

RuleNode {
  kind: [Getter: 93],
  range: [Getter] [ 0n, 170n, [length]: 2 ],
  rangeIncludingTrivia: [Getter] [ 0n, 170n, [length]: 2 ],
  type: [Getter: 0]
}

But that is not enough. To make it easier for developers to use this, we can do two things:

One: JSON serialization

• Expose the [serde] JSON serialization/deserialization through TypeScript APIs on each node. Example:
  • node.toJSON() -> string
  • Node.fromJSON(string) -> Node
• Expose TypeScript types for the RAW nodes (plain object fields instead of properties), to make it easy to share the CST nodes with other consumers, without having to rely on Slang NAPI boundary to interact with them.

Two: Debugger Visualization

They also reported having to implement their own serialization just to visualize the tree. Example:

Rule: SourceUnit "// SPDX-License-I..."
  Rule: _REPEATED "// SPDX-License-I..."
    Rule: Directive "// SPDX-License-I..."
      Rule: PragmaDirective "// SPDX-License-I..."
# ... redacted

However, instead of leaving it up to users, we can also provide such API, especially that we already have an internal one for unit tests snapshots:

We can probably expose this for both Rust and TypeScript, as a public API, with explicitly warning users that this is for dev-time visualization only, and its structure is subject to change at any time.

An additional benefit to this is that TypeScript will be able to generate the same visualization as Rust, unblocking #439