FileSystemProvider: How to interact with the filesystem in a CLI (w/o vscode)

[goto40]

When programming a CLI I do not have all aspects of my model in memory (only the model aspects from the files I decide to read; this is different from vscode where I have all models of my vscode project in memory).

So I need to decide which files to read (and then build my model from them) in order, e.g., to resolve all cross-file references.

One solution is to glob all model files. When loading fileNameI could glob all model files nearby "**/*.model".

    const documents : Array<LangiumDocument> = [];

    globSync(path.join(path.dirname(fileName), "**/*.model")).forEach(otherFileName=>{
        documents.push(services.shared.workspace.LangiumDocuments.getOrCreateDocument(URI.file(path.resolve(otherFileName))));
    });

    const mainDocument = services.shared.workspace.LangiumDocuments.getOrCreateDocument(URI.file(path.resolve(fileName)));
    documents.push(mainDocument);
    
    await services.shared.workspace.DocumentBuilder.build(documents, { validationChecks: 'all' });
    
    //... now check the validation results and generate whatever you need to generate

My question:

• Is this the way langium CLIs are meant to be built in case of multi file models (manually loading model files)?
• What is the role of the NodeFileSystem (should I use fs, path, and glob- or not/and why not)?

[msujew]

Hey @goto40,

Is this the way langium CLIs are meant to be built in case of multi file models (manually loading model files)?

While you can use Langium like this to build a CLI, it's probably easier to just use the services.shared.workspace.WorkspaceManager.initialize() function to initialize a whole folder and all documents within it. This is effectively what we call from the language server to initialize the whole vscode workspace (with all folders). If you need more fine grained control, you might want to go for the approach that you're already using though.

What is the role of the NodeFileSystem (should I use fs, path, and glob- or not/and why not)?

The NodeFileSystem allows anyone to build abstractions on top of any kind of file system. Since Langium is now generally available in browser use cases, we needed some way to split node.js dependencies (such as path and fs) from the rest of the framework. For any use case that relies purely on the file system of the user, NodeFileSystem is usually the best choice. However, in other cases you might want to use different kinds of file systems, such as the EmptyFileSystem which only works with files available in the editor and has no interaction with any actual file system. Other ideas include to load files from a remote location using a http request for example.