Will langium work well with 2 ambiguous file extensions like the form of .ts and .d.ts?

[jindong-zhannng]

Hi folks, I am building a Multiple Dependent Languages project with config like this:

{
  "projectName": "FormML",
  "languages": [
    {
      "id": "formml",
      "grammar": "src/language/formml/formml.langium",
      "fileExtensions": [".formml"],
      "textMate": {
        "out": "../vscode/syntaxes/formml.tmLanguage.json"
      }
    },
    {
      "id": "formml-declaration",
      "grammar": "src/language/formml-declaration/formml-declaration.langium",
      "fileExtensions": [".d.formml"],
      "textMate": {
        "out": "../vscode/syntaxes/formml-declaration.tmLanguage.json"
      }
    }
  ],
  "out": "src/language/generated"
}

I prefer to name their extensions to .formml and .d.formml. Notice that .formml is completely a subset of .d.formml. I don't know what algorithm langium is using to parse file extensions so I have these concerns:

1. Where the "fileExtensions" setting will be used?
2. Will langium's algorithm distinguish these 2 extensions correctly?
3. Will vscode handle this correctly?

I have tried to build things like above and seems vscode works well on calling correct language feature for different file extensions. But I think it would be better to confirm it again here. Thanks a lot.

[msujew]

Hey @jindong-zhannng,

yes, Langium generally doesn't have any issues with this, though you might need to override the shared ServiceRegistry service. AFAIK the function we're using yields .formml as the file extension even if it is a .d.formml file, so it's not able to differentiate between the two services by default.

[cdietrich]

yes this work. we have this usecase and we solved it by matching the longest matching file extension in our custom service registry

[jindong-zhannng]

Thanks @cdietrich @msujew, just for confirming, you mean I need to override ServiceRegistry.getServices method to do the longest matching in Langium side right? What about VSCode? Is there anything else I need to do there?

[cdietrich]

just the normal extensions in the languages section of packagejson work for us