Also adopt to "official" Dockerfile language server

[mickaelistria]

It seems like the dockerfile-language-server has been made upstream and official under docker organization: https://github.com/docker/docker-language-server . It would probably be best to use this one now.

[mickaelistria]

cc @rcjsuen : maybe something you'd like to help with?

[rcjsuen]

It seems like the dockerfile-language-server has been made upstream

This is not quite correct. At the moment they only overlap in Docker-related linting. The Docker Language Server does not provide code completions, hovers, semantic tokens, and so on for Dockerfiles. It does however provide editor features for Compose and Bake which the Dockerfile Language Server (as the name suggests) does not support.

[mickaelistria]

Ok, so from a client POV, it's better to stick to the dockerfile-language-server? Is there a plan to make dockerfile-language-server rely on upstream for linting, or should it be up to the client to set it up too?

[rcjsuen]

Ok, so from a client POV, it's better to stick to the dockerfile-language-server?

@mickaelistria Well, if you want the latest linting updates then you'd want to use the Docker Language Server. The advantage of the Docker Language Server is it supports build checks as it can call the Go code directly so you're more likely to see the same errors in the editor and at build time. The Dockerfile Language Server only does syntactical stuff and does not try to warn you against best practices because the landscape is ever changing and it is not easy to keep it synced with upstream.

And as aforementioned, if your users are using Compose and/or Bake then you'd want to give them the Docker Language Server.

If you end up deciding to run both language servers, you can use the experimental dockerfileExperimental.removeOverlappingIssues initialization options to get rid of the duplicates in the Docker Language Server. You can use this code for reference.

Is there a plan to make dockerfile-language-server rely on upstream for linting, or should it be up to the client to set it up too?

This is not straightforward as the original one is written in TypeScript and the new one is written in Go. Bundling binaries in an npm package comes with its own caveats as you can imagine and keeping it purely in TypeScript gives the language server more reach as you can run it in a browser.

[akurtakov]

As the "official" dockerfile ls is written in Go platform specific fragments for it have to be created thus there are no plans to add support for it unless someone contributes it.

[rcjsuen]

As the "official" dockerfile ls is written in Go platform specific fragments for it have to be created thus there are no plans to add support for it unless someone contributes it.

One alternative would be to download the binary at runtime kind of like what LSP4IJ does.