Cross-project model references in Langium (similar to Maven or multi-module setups)

[kuldeeparora89]

Hi,

I’m exploring how to enable cross-project model references in Langium — similar to how Java or Maven projects can depend on each other.

Scenario

I have a common DSL built with Langium (let’s call it mydsl).

There are multiple Langium projects (or workspaces) using this DSL to define their own models — for example:

project-a defines some entities.

project-b wants to reference entities from project-a.

These projects may not always exist in the same workspace. For example, project-a might be available as a built artifact in a local folder (e.g., ~/.m2/mydsl-models/project-a/) or a remote repository.

Goal

Allow cross-project scoping so that:

Models from dependency projects (like project-a) can be referenced in project-b using normal Langium cross-references.

The dependency models can be loaded from an external source (e.g., a compiled/indexed form or JSON snapshot).

The setup works even if the dependency project isn’t opened in the same workspace.

What I’ve considered

Creating a custom IndexManager that loads indices from other Langium projects.

Extending the ScopeProvider to include elements from these external indices.

Managing dependencies through a manifest file (e.g., dependencies.json or similar) listing the external model locations.

Questions

Is there any recommended or existing approach for supporting cross-project model references in Langium?

Are there any existing examples, references, that address multi-project dependency resolution?

Context

We’re building a system where several independently versioned projects use the same DSL but may reference each other’s models — conceptually similar to Maven or Gradle dependency management for Java codebases.

[spoenemann]

Most of this can be done in a custom WorkspaceManager which creates LangiumDocuments for external resources. The contents of these external documents can be loaded by the regular parser, through JSON AST snapshots, or through programmatic AST construction.

Visibility rules for your external resources should be implemented in your custom ScopeProvider, e.g. by overriding getGlobalScope and checking the origin of each symbol. This should take into account any manifest file you have; in order to make that efficient, you should create an in-memory model of that file and update it when the manifest changes.

A custom IndexManager can help if you want to pre-build the list of exported symbols for external resources. Depending on the location of a document (external or in current workspace), you can load the pre-built symbols or apply the standard procedure to find exports.