Best practice language specific workspace configs

[cdietrich]

Hi, is there any best practices for language specific configuration files in a workspace
(similar to .code-workspace but only valid for our langium based world.
what would be the best places to hook in?

[sailingKieler]

Hi @cdietrich,

that's a very general question.
I assume you wanna configure

• the language files to be taken into account in general, and/or
• control visibilities of referenceable AstNodes within such config files, don't you?

Loading and processing them within the workspace manager is always a good idea.
Once that happened your index manager, scope computation, scope provider, and validator may take that information into account.
The workspace manager itself may rely on that data while traversing the workspace folders and load the language files, of course.

Keep in mind that you might need to fire up and initialize the workspace manager in many/all of your unit tests you hopefully have. 😉

Does that answer your question?

[cdietrich]

the problem is the following.
we have packages in our system. they reside in certain base folders.
and now we want to use these packages, extracted from the uri
to do the indexing / name calculation
therefore we need a way to figure out where to look for packages
(we dont seem to be able to use code-workspace for non dsl reasons though)

[sailingKieler]

One option could be to implement a specific parser for you config files that builds up specific astNodes representing your configurations. Their types could even be defined in a Langium grammar file.
This way you can let the Langium document builder process your config files like your language files (which is pretty beneficial when it comes to config updates).

During the indexing phase you can let the indexer built up book keepings and traces allowing to identify which language document belongs to which package. Initial traces might also be collected in the workspace manager while traversing the folders and collecting files in order to avoid issues because of 'out of order' processing. You can also add specific information about each document on the LangiumDocument object, as it's quite unlikely that the package information for some document changes significantly without touching the document at all.

I did something similar once, it felt a bit fragile at the beginning but proved pretty stable over time.