kin-openapi
kin-openapi copied to clipboard
please user OrderedMap instead of the golang's map
The order of properties after each parsing is inconsistent.
Go maps iteration order is random, so I don't see why you mention deserialization?
Are you asking for this lib to use orderedmaps instead of maps so that operations can be deterministic? What's your use case? Do you see non-deterministic operations within the lib (that would be a bug)?
Also, what implementation of orderedmap would you recommend and why.
https://github.com/iancoleman/orderedmap
See also https://github.com/wk8/go-ordered-map v2 requires go18, which isn't a full year old https://go.dev/blog/go1.18
We have noticed that not only is the ordering inconsistent, which can make it a mess for people trying to read the yaml files, but the output yaml will also break a swaggerhub display. By default, yaml is output in alphabetical order. This places 'components' before 'paths' and that will break some definitions. All the definitions are there, and it does validate in swaggerhub BUT the display does not show the definitions. We've seen this so far with 'allOf'
schema:
allOf:
- $ref: '#/components/schemas/Guid'
- title: Incident guid
If we manually move the 'components' section to be after 'paths', then all is ok again.
Thanks for your feedback! We've got a couple github issues related to serialization order (and non-determinism must be annihilated) and I'm happy to hit two birds with one stone!
Note: solving this issue depends on https://github.com/wk8/go-ordered-map/pull/14#issuecomment-1336545760 if anyone want to help there ;)
Note: solving this issue depends on wk8/go-ordered-map#14 (comment) if anyone want to help there ;)
Seems like this is already implemented on https://github.com/wk8/go-ordered-map/pull/16
@chippyash Serialization order of fields is already adaptable. See openapi3.go and the MarshalJSON func implementation there. You should be able to reorder the fields there. I'll review your PR (provided you add a test for this ofc)
@codestation Look at my draft PR you'll see that's already being used :)
FYI progress on this is blocked by https://github.com/getkin/kin-openapi/pull/763 If anyone wants to take a look at the failing tests there...
@fenollp Any progress on this please?
Hi @chippyash Not much progress to report. Still blocked on #763 Comments welcomed!
The reason I'd like this: we generate our spec file and add it to git, and right now if we use MarshalJSON()
as it is, the order of parameters etc changes every time the command is run.
(I'm not expecting anyone to magically fix this, just providing reason for having order preserving.)