-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Formatting Docker Compose files removes the YAML document end #93
Comments
I'll take a look but I suspect it's a bug. I'll transfer this to the language service repo. |
Thanks @bwateratmsft ! |
@ferrarimarco Do you know if Docker Compose actually supports multiple YAML documents in one file? I've tried it out but it just seems to use only the first document and ignore everything else. |
The compose file spec supports merging multiple compose files. The spec doesn't say anything about multiple YAML documents in the same file. So I'd say that having multiple YAML documents in the same file is not a use case that Docker Compose supports, which is consistent with your test. I guess this makes this a formatting bug only, rather than one that causes a loss of functionality. I tried to have a look at where compose-language-server sets YAML formatting options it uses the yaml package to provide this feature, if I got the code correctly. There's one interesting option to play: From the yaml package docs
Unfortunately, I found no mentions of the document end marker |
Yeah, I'd noticed the same about |
Yup. Compose file are valid yaml files. Start and end markers can be there
even if you have a single yaml document in a yaml file, according to the
yaml spec. Given that both markers are optional, the formatter shouldn't
mandate either, nor strip any marker if it's there. Maybe this is due more
to a limitation of the yaml library that the formatter relies on, rather
than an explicit design choice?
Also, I was surprised about the name of that option, given that `---` is
actually the yaml document start marker, not the end marker.
|
The formatter works by parsing the YAML document and then rewriting it using the While the |
My use case is that I'm also parsing those yamls with other tools that use the document start and end markers to delimit those documents. |
Anyway, I think the formatter shouldn't alter that part of the document, as the "plain" yaml formatter is doing. It shouldn't enforce either choice, given that those are optional parts of the yaml spec. Or, at least, make it configurable. |
That makes sense. Can you open an issue at https://github.com/eemeli/yaml? It makes sense to me that the |
Done: eemeli/yaml#368 |
@bwateratmsft eemeli/yaml#368 was merged. |
@bwateratmsft Hi! It appears that the above PR made through the current eemeli/yaml release, so the necessary API should now be available. In the version that compose-language-service ships now, the document start marker is not stripped if it's there, nor it's added if it's not there. I'd expect the same for the next version, but I'm not sure if that applies to the doc end marker. |
It looks like |
Thanks! I'll have a look as soon as a new release of the extension is available. |
This is the related PR btw: microsoft/vscode-docker#3485 |
Glad to help! If you want to test it sooner, and you have Node.js installed, you can try out just the compose language service with the following steps:
I use this approach for testing, since it's a lot quicker than packaging, installing the package in the Docker extension, and building and running that. |
Hi all!
I noticed that formatting a Docker Compose file strips away the YAML end document marker (
...
). This doesn't happen if you manually set a Docker Compose file as a YAML file, and format it.Steps to reproduce:
compose.yaml
(although any other file name recognized by the dockercompose language definition would work).compose.yaml
file as a Docker Compose file (look for theCompose
language mode in the status bar (bottom right).The resulting, formatted file is:
While I was expecting:
Is this behavior something I can configure? Or is it a bug?
Thanks!
The text was updated successfully, but these errors were encountered: