kubeconform: Provide line number and column in case of validation errors

We are trying to use kubeconform as a library to build a language server that will expose manifest errors in the IDE. In order to best surface these errors, the line number and column of validation errors needs to be available. Currently, kubeconform surfaces the path to the invalid node, but there are some issues with how this is presented. In addition, this currently requires parsing the error returned from the error object, rather than through a rich interface exposing the underlying details.

Currently the path to an invalid node is exposed as foo.bar.baz. However, this has some issues. This form is ambiguous, as the path corresponds to both of the following:

foo:
  bar.baz: "qux"
foo.bar:
  baz: "quux"

With kubeval we were able to change the path separator from . to | and leverage the yaml.v3 to find the line number based on this path.

If kubeconform implemented its own Error and returned this with additional information, one that we could cast from an err.Error), then it would remain backwards compatible but allow downtream tools to extract extra information. It would be incredibly helpful (also to command line users) to expose the line and column number (which could be implemented by parsing into a Node using yaml.v3, and following the JsonContext), but even just exposing the JsonContext itself, to allow downstream tools to figure out things like the line/column number would be very helpful. In general, it would be great if some of the additional details that are jammed into the plain text error message were also available on this implementation to avoid needing to extract details from the error via regex.

We just wanted to get your thoughts on the best approach here given there are some alternative approaches (returning the line number and column from kubeconform itself, extending the error object, and/or returning the JsonContext via a custom error object.) There may be other approaches as well – so it’d be good to align on what makes most sense before moving forward.