replace numeric keys in yaml files with strings

[notEthan]

Description

I have replaced numeric keys in OpenAPI documents with strings, in accordance with the OpenAPI spec.

Motivation and Context

The OpenAPI spec requires that OpenAPI documents be expressable in JSON (v2 and v3). YAML allows any type to be an object key, but OpenAPI does not. v3 has an explicit note to this effect in its Format section; it applies to v2 as well.

I think swagger-editor should show an error when given YAML with non-string keys, but that doesn't look possible. The YAML parser (js-yaml) silently stringifies any object keys which are not strings, so swagger-editor's internals never see the integer keys. This is not the usual behavior of YAML parsers (and arguably not correct). I've opened an issue about this at nodeca/js-yaml#538, but that's beyond the scope of this issue.

Pending that issue, swagger-editor can at least be fixed to not show an invalid API document when you open the editor.

This has come up over at OAI/OpenAPI-Specification#2171

and stoplightio/spectral#955

How Has This Been Tested?

Given the YAML parser gives identical results parsing string and integer keys, and that's all I've changed, no tests or code should need any change.

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[shockey]

Approved!

This is not the usual behavior of YAML parsers (and arguably not correct)

I'm going to avoid endorsing whether this is Correct™, but I do agree that this change is less confusing than having mapping keys that could be parsed as numbers.

[shockey]

please build

[notEthan]

thanks @shockey !