implement property key completion

[srivastava-diya]

Adds property-key completion, for properties keyword for now.

• MatchingSchemaCollector collects the properties keyword's value directly during validation through afterKeyword.

• Completion and Hover now resolve the AST node via findNodeAtPosition and read annotations from it.

• validateSchema uses jsonc.parse.

• Tests : no properties, flat properties, nested object properties.

[srivastava-diya]

I had a doubt, for example lets look at this oneOf schema.

{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "oneOf": [
      {
        "properties": {
          "foo": { "type": "string" },
          "bar": { "type": "string" }
        }
      },
      {
        "properties": {
          "foo": { "type": "string" },
          "baz": { "type": "string" }
        }
      }
    ]
  }

And a user is typing this instance

{
    "$schema": "${fixtureSchemaUri}",
    ""
}

here two oneOf branches both match simultaneously and there's no discriminant, so the instance is technically invalid as per JSON Schema since it matched more than one, but we still offer the union of both branches properties rather than recognizing this as an issue in order to show something for completion, so i wanted to ask if this is the right thing to do here or some other behaviour is expected?

[srivastava-diya]

also i wanted to ask if i am proceeding correctly? and if i am then how should i strengthen anyOf and oneOf completions? like should i think about more edge cases, add more tests or something?

[jdesrosiers]

here two oneOf branches both match simultaneously and there's no discriminant, so the instance is technically invalid as per JSON Schema since it matched more than one, but we still offer the union of both branches properties rather than recognizing this as an issue in order to show something for completion, so i wanted to ask if this is the right thing to do here or some other behaviour is expected?

I think we want it to behave as much like TypeScript as possible. So, if there are no properties yet, it should show all possibilities,

If there's a matching discriminator, we can filter

also i wanted to ask if i am proceeding correctly? and if i am then how should i strengthen anyOf and oneOf completions? like should i think about more edge cases, add more tests or something?

Yes. It looks great so far. Keep trying to come up with edge cases that might break. Something to consider is properties with invalid values and how that affects discriminators and filtering. For example,

In this case, the "baz" property should be presented correctly despite "bar" having an error.

[srivastava-diya]

I think we want it to behave as much like TypeScript as possible. So, if there are no properties yet, it should show all possibilities,

Sure.

In this case, the "baz" property should be presented correctly despite "bar" having an error.

This one is interesting, gonna add a test that covers this behavior.

[jdesrosiers]

I only had time to get through the tests, but they look great! I think the only thing left for this issue if figuring out what how not should work.

[jdesrosiers]

I think this should include "a" as well, right? "c" is passing in alternative 2, but there is nothing in alternative 1 that matches "c" and fails. So, I would expect both "a" and "foo" to be suggested.

[srivastava-diya]

Yes makes sense, I'll add the "a" as well

[srivastava-diya]

I think the only thing left for this issue if figuring out what how not should work.

yeah and in addition to that i also need to implement the auto : insetion after selecting a property which would be fairly simple but i was thinking i should Also implement the : "" insertion for string , : { } for objects etc. which would require us to look at the subschema of the property, so i was thinking if it is the right time to do it? or would the mechanism be simpler if we do this while we're working for Value-completion.

[jdesrosiers]

I'd consider that value completion to me. Let's get this merged first and work on that next.

[srivastava-diya]

The property names a single branch's properties keyword declares, it lives on the branch's schemaContext

[srivastava-diya]

passedProperties the names of properties whose values were valid, added there by each property's own check as it finishes.

[srivastava-diya]

failedProperties Same as above, but for evaluations that returned not valid. Also keyword-scoped so properties, additionalProperties, and patternProperties each accumulate their own.

[srivastava-diya]

rejectedProperties The branch level union of every failedProperties set added in from properties additionalproperties , patternproperties under that branch

[srivastava-diya]

Hey @jdesrosiers following up on not implementation I think for propertycompletion, the only case that actually matters is not containing required, imo that's the one that forbids a key from existing, so it should be excluded from suggestions. A not wrapping something like properties/const/type restricts values so i think we can leave those right?

[srivastava-diya]

I think this is ready for a look. Property key completion is working with not case included.