Is there a mechansim corresponding to the XText "importURI" feature

[goto40]

I wonder if there is already a way to implement the "importURI" mechanism from XText?

I would like to create a DSL which is able to import other files. Example:

persons.dsl:

person Tom
person Jerry

main.dsl:

import "persons.dsl"
hello Tom!

is there already something included in langium to enable this?

[msujew]

Hi @goto40

By default, every element is exported from a file and available for referencing in the global scope. You should be able to restrict this (to only scope to elements which are imported) by overriding the default scope provider. Alternatively, you can keep it loose and validate that only references are valid to files which are declared as being imported. That's how we currently do grammar importing for the langium grammar language.

I'm sure @spoenemann has more to say about that ;)

[goto40]

I found my error - I forgot to update the index (compare domain-model-index.ts in the domain model example in the langium repository).

Thank you @msujew !

[goto40]

In that case, it might be that you're missing the call to the global scope:

I did not have the problem with my custom ScopeProvider (which worked as expected - see #401
but with my ScopeComputation...

export const ItemLanguageModule: Module<ItemLanguageServices, PartialLangiumServices & ItemLanguageAddedServices> = {
    references: {
        ScopeComputation: (injector) => new ItemLangScopeComputation(injector),
        ScopeProvider: (services) => new ItemLangScopeProvider(services),
        NameProvider: () => new ItemLangNameProvider()
    },
    ...
    index: {
        AstNodeDescriptionProvider: (services) => new ItemLangNameDescriptionProvider(services)
    }

I have to take my time to understand the details. But I am happy with the overall behavior now: I basically implemented what is described in the domain model example (including the index module). With this everything seems to work (except for some auto completion issues - I need to see what they have in common before continuing here / maybe everything is ok).

Thank you again for the prompt reply!

[goto40]

Thank you very much for your help in this topic so far!

While trying to implement the "importURI"-validation to restrict references to "imported URIs" (as suggested by @msujew ) I encountered a problem:

I tried to make a generic validator (type independent) to iterate over all references of the model. However, when generating the error I could not restrict the error to the property matching the exact location in the document (only to the entire AstNode): the accept-call below does not accept the property...

The ValidationAcceptor is not type independent (it is type safe, for good reasons). Is this the correct way how to implement this? Could you give me a hint or link (to the "langium grammar language"?) where to have a look?

    checkModelIncludes(msg_model: MsgModel, accept: ValidationAcceptor) : void { // MsgModel is the root of a model
        const doc = msg_model.$document;
        console.log(`ref check for ${doc?.uri.fsPath}`);
        if (!doc) {
            throw new Error("unexpected: no document found for model.");
        }
        streamAst(msg_model).forEach((node)=>{
            streamReferences(node).filter((description)=>{ // initial simple check: do only allow ... 
                return description.reference.$nodeDescription?.documentUri != doc.uri && // ... local refs
                    description.reference.$nodeDescription?.documentUri.toString() != "memory://built_in_0.item"; // ... and refs from here
            }).forEach((description)=>{
                accept('warning', 'include Problem.', { node: description.container /*, property: description.property*/ }); // property not known/matching
            })
        });
    }

[msujew]

Hm, I see the issue there. Maybe we can relax the type safety there and accept any string for the property if the node is of type AstNode. Anyway, you can always do this to circumvent type issues:

{
  node: description.container,
  property: description.property as any,
  index: description.index
}

[goto40]

Thank you, @msujew : your workaround is working.

[spoenemann]

I agree with the approach of validating imports. The advantage: not imported elements stay in scope and so completion and go-to-definition work for them.