Add a compose language

[alexr00]

I heard from @bwateratmsft that adding a compose language would be useful for the docker extension, and I think it might make sense. It's easy to try this, so I figured why not. Some of the reasons this could be useful:

• Extensions can use compose as the language for activation
• Simplifies when clauses for users who what to scope things
• Easier to show the proper icon for icon themes
• Nice to use in files.associations

[alexr00]

@chrmarti FYI

[bwateratmsft]

• Extensions can use compose as the language for activation

I wanted to expand on this some; from telemetry it appears that around 60% of our (Docker extension) activations are due to opening a yaml document, and around 30% are from opening a Dockerfile. Certainly not all of those 60% are actually compose documents (not really sure just how many are), so those would be spurious activations. @alexr00 suggested we could also look at the workspaceContains activation event, which would sorta work, sorta not. Compose documents probably don't get very frequently edited, so I wouldn't necessarily want to activate every time a workspace containing one is opened--there's a good chance it won't be touched in any given session. If it isn't opened, then that would also be a spurious activation.

• Simplifies when clauses for users who what to scope things
• Nice to use in files.associations

Users have a lot of variability in file naming for Docker-related stuff. Dockerfiles probably have this more, but compose documents are no exception. Allowing users to adjust files.associations is the easiest way for them to ensure their document is considered a compose file, both for the purposes of everything language-related (highlighting, potential language server features, etc.), but also for all the commands that are scoped to compose docs--for example, our right click > Compose Up command.

This issue has a lot of our reasons for wanting this, and links several issues that we duped against it, in order to gather up everything related. Up until this morning when I spoke to Alex we were tentatively planning on duplicating the yaml grammar straight from VSCode and defining the language, but I was wondering if there was a better way than code duplication--so I asked, and @alexr00 recommended this!

[bwateratmsft]

Discussed in the chat, but is this case-sensitive?

[alexr00]

I don't have a linux VM to test this on at the moment, but looking at the code it seems that we toLower the pattern so it should be case-insensitive.

vscode/src/vs/base/common/mime.ts

Lines 174 to 182 in e8760a5

	// Longest pattern match
	if (association.filepattern) {
	if (!patternMatch || association.filepattern.length > patternMatch.filepattern!.length) {
	const target = association.filepatternOnPath ? path : filename; // match on full path if pattern contains path separator
	if (match(association.filepatternLowercase!, target)) {
	patternMatch = association;
	}
	}
	}

[chrmarti]

Would it make sense to disambiguate it as "docker-compose"?

[alexr00]

Seems reasonable to me. I can change it.

[aeschli]

Maybe call the language dockercompose. That would be consistent to language dockerfile. Also *compose*.yml is a bit risky and might too much. I would just go with docker-compose.yml.

[bwateratmsft]

Also *compose*.yml is a bit risky and might too much. I would just go with docker-compose.yml.

It needs to be more broad. Here's a sampling of a bunch of valid, (mostly) realistic compose file names:

docker-compose.yml
docker-compose.yaml
docker-compose.override.yml
docker-compose.debug.yml
docker-compose.foo.bar.baz.yml
compose.yaml
compose.yml
compose.override.yaml

The list goes on eternally...the only thing I think is reliable is that it's nearly always a yaml extension (yml or yaml), and "compose" appears in the filename nearly always. Sure, you could start to list them off more specifically, but it becomes a maintenance headache.

Something a little less broad that I think would still cover most of our bases:

"filenamePatterns": [
    "compose.yml",
    "compose.yaml",
    "compose.*.yml",
    "compose.*.yaml",
    "*docker*compose*.yml",
    "*docker*compose*.yaml"
]

That would match everything in the list above, but not "composer.yaml" or something along those lines that would (probably) not be a compose document.

[alexr00]

Seems like there are no objections, so I'm going to merge this.