Fair enough, fixed, thanks

I'm confused here; so this is using;
https://github.com/moby/buildkit/blob/v0.10/frontend/dockerfile/dockerfile2llb/image.go

That type is effectively deprecated in v0.11 of BuildKit (but not aliased but defined as a duplicate of the type);
https://github.com/moby/buildkit/blob/v0.11.0-rc1/frontend/dockerfile/dockerfile2llb/image.go#L11

The new type is here:
https://github.com/moby/buildkit/blob/v0.11.0-rc1/exporter/containerimage/image/docker_image.go

And, IIUC, it's effectively a fork of the type that is defined in Docker.

So, docker now depends on a fork of itself to define the type?
https://github.com/moby/moby/blob/v23.0.0-beta.1/api/types/container/config.go#L35-L54

Can we fix this, because this looks really weird

The last type you linked is an api type, we shouldn't use it for reading things, only for writing to it and sending to the caller.

That being said then moby doesn't have any type that defines a HealthConfig.

But how is the dockerfile2llb type different? That's also an API type; it's the type to export to JSON

The dockerfile2llb type is used to store the image, that's why it's later moved over to the exporter. We should use the same type that is used to save the image when we load it. Then we can convert it to our own types.

This type is the type that we use for the engine API. It should be independent of anything else.

Put in another way: the dockerfile2llb type is different in a sense that it's a buildkit's type. We have our own for the engine API. They both look the same, but they are not the same