Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Escape colon #371

Open
VonSerpe opened this issue Oct 23, 2019 · 14 comments
Open

Escape colon #371

VonSerpe opened this issue Oct 23, 2019 · 14 comments

Comments

@VonSerpe
Copy link

Detailed description

When I create an example with a value that contains a colon like this:

range:
  summary: Bla bla bla
  value:
    range: '4:23'

speccy resolve command converts the range value string in a value without quote:

range:
  summary: Bla bla bla
  value:
    range: 4:23

and in SwaggerHub editor I see this:

{
  "range": 263
}

Possible implementation

When quotes are used to define the value of a variable, speccy resolve command can consider the quotes and apply them to the generated file

Your environment

Include as many relevant details about the environment you experienced the bug in and how to reproduce it.

  • Node Version: v10.16.3
  • Operating system and version (e.g. Ubuntu 16.04, Windows 7): macOS High Sierra 10.13.6
@philsturgeon
Copy link
Contributor

@MikeRalphson this might a thing for oas-resolver?

@MikeRalphson
Copy link
Contributor

This is unrelated to oas-resolver. This is purely due to Speccy's yaml parsing and serialization functions. 4:23 cannot be interpreted as a boolean, number or null, therefore it is a string by default and does not require any quoting. Probably a bug in SwaggerHub.

@negebauer
Copy link

I'm having a similar issue with a date. I have the following

example: '2019-10-10'

That speccy transforms to

example: 2019-10-10

But I want the example to be treated as a string, is there any way I can force speccy to respect this quote? It should respect it by default right?

@MikeRalphson
Copy link
Contributor

2019-10-10 cannot be interpreted as a boolean, number or null, therefore it is a string by default and does not require any quoting. Probably a bug in SwaggerHub.

@negebauer
Copy link

negebauer commented Jul 14, 2020

It can be interpreted as a date, which is what's happening. That's why the quotes should be preserved in this case. It's not a string by default.

js-yaml issue where it's mentioned that 2019-10-10 is read as a date nodeca/js-yaml#198

swagger-ui issue where a similar case is mentioned with the solution being to add the quotes swagger-api/swagger-ui#5061 (comment)

@negebauer
Copy link

Another option from the YAML spec is to use tags like example: !!str 2019-10-10 but speccy resolve also deletes the !!str part

@MikeRalphson
Copy link
Contributor

MikeRalphson commented Jul 14, 2020

From the OpenAPI spec:

In order to preserve the ability to round-trip between YAML and JSON formats, YAML version 1.2 is RECOMMENDED along with some additional constraints:

Tags MUST be limited to those allowed by the JSON Schema ruleset.

Keys used in YAML maps MUST be limited to a scalar string, as defined by the YAML Failsafe schema ruleset.

The JSON Schema ruleset does not include the date type.

@negebauer
Copy link

Oh it's because of the JSON Schema then. It's not a bug then as you said. Thanks!

For anyone that ends up here I used this workaround to preserve the quotes:

example: |
  2019-10-10

@negebauer
Copy link

I think this issue can be closed then, right?

@MikeRalphson
Copy link
Contributor

I said it was probably a bug in SwaggerHub. If they're not limiting their yaml parsing to the JSON Schema ruleset, then that's a bug.

@MikeRalphson
Copy link
Contributor

All issues here should be closed. Speccy is unmaintained.

@negebauer
Copy link

I mean that it's not a problem with speccy

@MikeRalphson
Copy link
Contributor

Ah, apologies for misreading.

@negebauer
Copy link

negebauer commented Jul 14, 2020

no problem, I should have been more clear :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants