Mapping keys do not have to be a string, and may be a number

[BigBlueHat]

Describe the bug It looks like a JSON requirement has snuk into this YAML parser.

On line 335 of parseWithPointers.ts the following error is thrown:

mapping key must be a string scalar rather than a number

However, I'm not able to find that requirement in the YAML 1.2 spec, nor in various other YAML parsers I've tried.

JSON can't handle {5: "five"}, but YAML seems happy to deal with 5: five (for example), so this feels like a "leak" from JSON-land back "up" into YAML land.

Numbers as keys show up frequently in OpenAPI documents...and really shouldn't be throwing errors (per YAML):

paths:
  /:
    get:
      responses:
        200:
          description: woot!

Expected Behavior YAML allows numbers as mapping keys, so this library shouldn't throw an error.

Cheers! 🎩

[P0lip]

@BigBlueHat

However, I'm not able to find that requirement in the YAML 1.2 spec, nor in various other YAML parsers I've tried.

You are right. That's not a requirement in YAML. In fact, a mappings with string scalar and a mapping with a numeric scalar are two different properties. YAML can even take complex values as a mapping key, so it get can even more quirky.

JSON, on the other hand, can only take strings as keys.

JSON can't handle {5: "five"}, but YAML seems happy to deal with 5: five (for example), so this feels like a "leak" from JSON-land back "up" into YAML land.

Yeah, we treat YAML in a JSON-ish way by default inside of Studio.

[BigBlueHat]

Gotcha. Might be good to note that caveat in this package as it makes it less of a "pure" YAML parser/processor and more of a JSON-focused YAML wrangler thing. 😃

Thanks for the explanation!

[Ravikumar109]

Is there a possibility of overwriting the error messages for yaml when linting and customizing the rules using spectral

[P0lip]

That is not possible at the moment.

[Ravikumar109]

@P0lip i have added '' for the http codes in the raml specs and it is not throwing any error at line 64 but if it not used like having 201 at 76th line it is throwing error due to the validation done by spectral but with the error it is still a valid yaml so from my understand from the above statement to resolve the error messages i need to use quote as customization is not possible. Is that correct statement

[P0lip]

Is that correct statement

Correct, you need to use quotes everywhere to resolve the errors.

[dcal]

Is this something that could be fixed? It feels weird to have to adapt valid YAML in projects just for the sake of satisfying a quirk of the parser.

[publicvirtualvoid]

I have quite a lot of external $refs and can't really go and update everything - is there a way to turn this behaviour off? Given that this is valid OpenAPI spec for HTTP responses it's kind of a big use-case.