Parse errors make parsed tree useless

[vinnichase]

I have the following code snippet that can be run in node:

const { parseTree } = require('jsonc-parser');

const correctObj = '{"prop1":"foo","prop2":"foo2","prop3":{"prp1":{}}}';
console.log(parseTree(correctObj));

That produces the following correct output:

<ref *1> {
  type: 'object',
  offset: 0,
  length: 50,
  children: [
    {
      type: 'property',
      offset: 1,
      length: 13,
      parent: [Circular *1],
      children: [Array],
      colonOffset: 8
    },
    {
      type: 'property',
      offset: 15,
      length: 14,
      parent: [Circular *1],
      children: [Array],
      colonOffset: 22
    },
    {
      type: 'property',
      offset: 30,
      length: 19,
      parent: [Circular *1],
      children: [Array],
      colonOffset: 37
    }
  ]
}

However if I run it on a slightly malformed object like so (two double quotes in prp1):

const malformedObj = '{"prop1":"foo","prop2":"foo2","prop3":{"prp1":{""}}}';
console.log(parseTree(malformedObj));

I get a tree with two nodes which represent key and value of prop1:

<ref *1> {
  type: 'property',
  offset: 1,
  length: 13,
  children: [
    {
      type: 'string',
      value: 'prop1',
      offset: 1,
      length: 7,
      parent: [Circular *1]
    },
    {
      type: 'string',
      offset: 9,
      length: 5,
      parent: [Circular *1],
      value: 'foo'
    }
  ],
  colonOffset: 8
}

That makes it impossible to figure out which node is for example at offset 48.

My use case: I'm writing a VSCode extension for JSON completion. When the user starts typing, the object will always be malformed so that I get no information on the node which he is typing in.

Have you similar use cases and maybe solved it differently or is there any way to increase fault tolerance of the parser? My current workaround would be to remove the current word range from the text and parse the tree based on that. I'm by far not sure if this works in every possible situation.

[vinnichase]

Any comments, why this is closed now?

[aeschli]

It's fixed by 53456f5. I will publish a new version in the coming days.