kubernetes-sigs / json Goto Github PK

View Code? Open in Web Editor NEW

24.0 5.0 16.0 241 KB

Golang JSON decoder supporting case-sensitive, number-preserving, and strict decoding use cases

License: Other

Makefile 0.23% Go 98.71% Shell 1.06%

k8s-sig-api-machinery

json's Introduction

sigs.k8s.io/json

Introduction

This library is a subproject of sig-api-machinery. It provides case-sensitive, integer-preserving JSON unmarshaling functions based on encoding/json Unmarshal().

Compatibility

The UnmarshalCaseSensitivePreserveInts() function behaves like encoding/json#Unmarshal() with the following differences:

JSON object keys are treated case-sensitively. Object keys must exactly match json tag names (for tagged struct fields) or struct field names (for untagged struct fields).
JSON integers are unmarshaled into interface{} fields as an int64 instead of a float64 when possible, falling back to float64 on any parse or overflow error.
Syntax errors do not return an encoding/json *SyntaxError error. Instead, they return an error which can be passed to SyntaxErrorOffset() to obtain an offset.

Additional capabilities

The UnmarshalStrict() function decodes identically to UnmarshalCaseSensitivePreserveInts(), and also returns non-fatal strict errors encountered while decoding:

Duplicate fields encountered
Unknown fields encountered

Community, discussion, contribution, and support

You can reach the maintainers of this project via the sig-api-machinery mailing list / channels.

Code of conduct

Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.

json's People

Contributors

Stargazers

Watchers

Forkers

liggitt isgasho j2gg0s zakir-code frankfanslc dropthemasquerade kubelib chuanyi-zjc jbadru73 isabella232 kevindelgado devcloudyy rocaltair pcanilho sithembiso-mashinini

json's Issues

Provide the location of unmarshal errors within the JSON object

When an unmarshal fails, such as when disallowUnknownFields is set, it returns an error such as json: unknown field "foo".

We would like some sort of context on where within the JSON object the unknown field exists. There are many instances where the same field name exists multiple times in an object and so without that context it can be hard to tell where the error came from. For example, large CRDs can have many “description” fields. If one of those “descriptions” is misplaced within the object it will be really difficult to track it down.

Simple playground example: https://play.golang.org/p/je8-WmSD1vE

Project support for Go 1.16

Currently, this project is advertised as supporting Go 1.16 in the project go.mod. However, the project uses functionality introduced in Go 1.17 (1, 2) that does not exist in Go 1.16. This is resulting in downstream packages breaking when trying to build with Go 1.16 and the Go module system not detecting the incompatibility.

Ideally this project would support Go 1.16 as it is still a supported version by the Go language maintainers. If that is not possible, it makes sense to bump the minimum version of Go supported in the main go.mod to allow these errors to be caught by go tooling.

.

sf.Exported undefined i'm understand

Please use a regular Apache 2.0 LICENSE

Adding exceptions to the LICENSE file makes it difficult for consumers to determine whether this component can be considered released under Apache 2.0. The assumption then becomes that it isn't, which probably wasn't the intention when adding the exception?

Provide the location of unmarshal errors besides ‘UnmarshalTypeError‘

When the pod quantity (seen in k8s.io/apimachinery/pkg/api/resource) unmarshaler fails because the filed and the regular expression does not match, it just returns an error as "quantities must match the regular expression '^([+-]?[0-9.]+)([eEinumkKMGTP][-+]?[0-9])$'".

We would like some sort of context on where within the JSON object the unknown field exists. There are many instances where the same field name exists multiple times in an object and so without that context it can be hard to tell where the error came from. For example, pod can have many "sizeLimit" fields in "Mounts". If one of those “sizeLimit” is mistaken within the object it will be really difficult to track it down.

Create a SECURITY_CONTACTS file.

As per the email sent to kubernetes-dev[1], please create a SECURITY_CONTACTS
file.

The template for the file can be found in the kubernetes-template repository[2].
A description for the file is in the steering-committee docs[3], you might need
to search that page for "Security Contacts".

Please feel free to ping me on the PR when you make it, otherwise I will see when
you close this issue. :)

Thanks so much, let me know if you have any questions.

(This issue was generated from a tool, apologies for any weirdness.)

[1] https://groups.google.com/forum/#!topic/kubernetes-dev/codeiIoQ6QE
[2] https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS
[3] https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md