Vscode: VSCode default language extensions override custom language extensions

[robertohuertasm]

• VSCode Version: 1.9.0
• OS Version: Windows 10

Steps to Reproduce:

1. Install vscode-icons
2. Install Vue language extension
3. Create a new file with the .vue extension.
4. Instead of the Vue icon the html icon is shown.

vscode-icons provides support for Vue files by leveraging the language id but it seems that the mechanism that it's used by the icon theme API is giving priority to the default language extensions provided by VSCode.

This has an unexpected behavior as the users are not able to see the expected icon.

In the case of Vue, you can see where it is associated to html in VSCode's code in the html extension as @JimiC pointed out in vscode-icons #725.

This is the only case where the file association has to be explicit, meaning that the user has to explicitly change the file association so she can see the proper icon. That's not the case when the language id is not provided by default by VSCode.

This is clearly creating inconsistencies in the user experience thus confusing the users about what they are supposed to do.

It would be nice if this could somehow be changed to prioritize custom language ids over default ones. This is at least what we were expecting from our side as icon theme builders until we've found out that this is not how it seems to be working.

[JimiC]

@aeschli
After a three hours debugging session, I figured out what's going wrong.

There are three factors that are causing this misbehavior.

1. .vue is also registered as an extension for the html language id in the internal support of html syntax highlighting as already mentioned.

1. Although vscode issues a warning about the extension getting overwriten, it doesn't get handled, in order for the internal association to get removed from the appropriate list (nonUserRegisteredAssociations).

2. While iterating through the association list (in this case the nonUserRegisteredAssociations), the flow logic prevents the correct mime to be assigned, as it gets assigned to html because the iteration finds the html first and then prevents the flow to get through to vue.

My proposed solution is to handle the issue in the already coded check section.

[aeschli]

Thanks @JimiC for the investigation and the detailed write-up!

[JimiC]

@alexandrudima Do we have any news on this? Is it OK if I provide a PR with my proposed solution?

[alexdima]

Appears to be in mime.ts

[JimiC]

Actually the flow starts from https://github.com/Microsoft/vscode/blob/master/src/vs/editor/common/services/languagesRegistry.ts#L301 but the main logic is in mime.ts.

[bpasero]

I cannot reproduce:

• installed vscode-icons
• installed vue extension
• opened a foo.vue file

=> icon shows up correctly
=> language in status bar reads Vue.js

[JimiC]

@bpasero I know, this is now invalid as you guys removed the vue filename extension from the html extension. But try this with the asp or volt extension.

[bpasero]

@JimiC it is not clear how to solve that though, there are 2 extensions that provide a language for an extension and the first one wins, but how do you argue that the second one should win? What are the rules?

[JimiC]

As we have discussed this with @robertohuertasm internally, a way to solve this is to introduce an extra level in the determination logic.

Currently, the logic is:

• filename
• filename extension
• language id

We propose it to become:

• filename
• filename extension
• language id (external extension)
• language id (internal extension)

This can be achieved by removing the internal mime association from the list if an external extension supports the same filename.

Now, I don't know the implications of this approach as I'm not familiar with the entire code base of vscode. I'm sure that there will be cases where the user may have installed more than one extension that support the same mime type. Or even cases where the external extension references the same language id as an internal one. Current examples are the rails and Flow extensions.

[bpasero]

@JimiC I am not a big fan of "internal" vs "external" extension, to me they are all the same and the fact that they behave differently is imho debt. And since the issue exists also when installing multiple external extensions, I think the real fix is some way of configuring this per extension.

[JimiC]

Understandable but the issue here is that the user doesn't have a "clear" way to tell vscode to override the "internal" extension. There is a workaround though explained here.

[bpasero]

This is the problem:

• user installs extension foo
• user installs extension bar
• foo registers support for *.foo and *.bar
• bar registers support for *.bar

=> as a user I want to control that extension foo only deals with *.foo and extension bar deals with *.bar

I see no other solution that does not add more confusion or complexity.

@aeschli @alexandrudima let me know what you think

[JimiC]

Exactly what I'm saying. Currently, the logic determines that *.bar is handled by foo and stops there returning that foo is the mime type. What I'm proposing is that the logic keeps iterating and if it finds an extension that solely handles *.bar returns that as mime type. This also has its own complexity.

What if:

• user installs extension foo
• user installs extension bar
• foo registers support for *.foo and *.bar
• bar registers support for *.bar and *.alcohol

?

[bpasero]

So now you are proposing that an extension that registers only for one extension is more important than one with more extensions? Not sure about that...

[JimiC]

Just throwing ideas and questions here. I have already mentioned that I'm not familiar with the entire code base and I don't know the implications my proposals can create.

I have to admit though that this is a "Lerna" problem and we definitely need a "Hercules" solution.

[bpasero]

I think this is more of a UX question ("how should it behave") than a question of how it is implemented in the end 👍

[JimiC]

@bpasero Thinking of it over the weekend I concluded that there are two possible behavior solutions:

1. Give the ability to the user to disable the built-in extension.
2. installed extension should always be preferred over the built-in as the installed ones can be disabled by the user.

In case two or more extensions support the same filename extension then it's up to the user to disable the one that creates an issue.

Appendix:

• installed the extension/extensions that the user can install.
  
  
  
  • built-in the built-in extension/extensions supported by vscode.
  
  

[bpasero]

@JimiC 👎 I would say that this should go on the level of the file extension and not entire extension. If the user is forced to disable an extension, then the user is loosing all functionality of this extension for all file extensions this extension configures. There may still be a very good reason why the extension should not be disabled.

Imagine HTML was an extension in the store: The user is now forced to disable the HTML extension so that the ASP extension works. But that means loosing all the functionality of the HTML extension for all other file types.

[JimiC]

Then 2. is the only option.

[bpasero]

I disagree. Solution 3. imho is: Allow to control for any extension (either built in or installed) if a file association should be made from that extension or not. In other words: Given an extension *.foo, should extension Foo provide the language features or not.

[JimiC]

I think this is already available by setting

"files.associations": {
    "*.foo": "foo"
}

Correct me if I'm wrong.

[bpasero]

Yeah. maybe a little less obvious and hard to discover for users.

[JimiC]

So, is this the officially proposed way to deal with those cases? Issue closed?

[bpasero]

@JimiC no I think the official way of doing it would be from the extension itself, e.g. here:

I could maybe have a way to disable a specific association of a language with a file pattern.

[JimiC]

And what about when it's a filename extension in a built-in extension?

[bpasero]

@JimiC from a user point of view I see no reason why such configuration ability should not apply to any kind of extension (either built in or external). In the end I think all extensions should be treated equally.

[alexdima]

In general extension contribution point collision is handled the following:

• built-in vscode extensions are processed in the fs.readFile order (which is AFAIK consistent alphabetical)
• user vscode extensions are processed in the fs.readFile order (also alphabetical AFAIK).
• vscode extension(s) under development

So assuming vscode extensions Y and X are built-in, C and D are user installed extension and A and B are extension(s) under development, the processing order of the extensions would be: X, Y, C, D, A, B.

In case of collisions, in extension points I write, I try to implement "overwrite semantics". e.g. if extension X contributes a TM grammar for typescript, then any of the extensions Y, C, D, A or B would win if they contributed a TM grammar for typescript. The same is true I think for most of the extension points. This plays out well as user installed extensions can "overwrite" contribution points of built-in extensions.

The mime detection is quite complicated, as there are so many different ways to associate a file with a language id, but, if possible, I would try to implement the "overwrite semantics": e.g. if a built-in extension associates ".html" => html and comes a user installed extension that associates ".html" => someotherlanguage I would let the user installed extension "win".

[bpasero]

@alexandrudima isn't the consequence of this change is that if a user has an extension installed that happens to also register for *.html, suddenly all HTML support would change and the only solution is to uninstall the installed extension (that might provide something smart for another language the user is using).

Are we sure we are willing to potentially break these users (if my assumption is right)?

[bpasero]

After talking to @alexandrudima we decided to go forward with the model of letting a user installed extension override our built in extensions.

I have added a new property userInstalled to ITextMimeAssociation for the registerTextMime method that is being used to register all languages. This property should be set to true for extensions that are originating from the extensions folder and not our installation directory.

I did not find any property on ILanguageExtensionPoint that would tell me if the extension point is contributed from a built in or user installed extension.

@sandy081 is there any chance we could add this info to extension point handler here? I think that is the only piece missing.

[sandy081]

Yeah that information is already there in extension description. You can get it as follows

extensions[i].description.isBuiltin

[bpasero]

@JimiC please verify from tomorrows insider build

[JimiC]

@bpasero Confirming that behavior is as excepted in today's insider version. 👍
Test done with asp and volt.

[bpasero]

@JimiC awesome thanks.

[JimiC]

@bpasero It has been reported to us that due to this change there is an issue with the scss association (only noticeable in Code-Insiders). Using the sass-intended extension the icon association for scss gets lost. This line may cause the issue.

[bpasero]

@JimiC can we extract this into a new issue?

[JimiC]

@bpasero Sure.