Node.js support and restructuring to monorepo

I am seeing increasing demand for a Node.js backend for Sprotty. I already created an example for that about a year ago:

https://github.com/spoenemann/theia-sprotty-nodejs-example/blob/master/diagram-view/src/node/diagram-server-impl.ts

I would like to share this to the Sprotty project as a separate package. At the same time, I propose to change this repository to a monorepo with multiple packages:

• sprotty
• sprotty-elk (moved from eclipse/sprotty-layout)
• sprotty-node (new)
• sprotty-protocol (new)

This will make it considerably easier to keep the code synchronized and to implement cross-package functionality.

I’d leave sprotty-theia and sprotty-vscode separate because their dependency tree is more complex, and I have previously seen problems when trying to include both the Theia and the VS Code integration in the same Yarn workspace. I would also keep sprotty-server separate to avoid a mixed-platform repository (TypeScript / Java).

sprotty-node should not have a dependency to sprotty to avoid using browser code in a Node.js context. For that reason, we need to extract common data structures into a new package sprotty-protocol. This is also a good opportunity to isolate and document the client / server protocol of Sprotty more clearly. For now that new repository should contain

• SModel (schema) declarations
• Actions (#233)

In order to keep API breakage at a minimum, we could mark the original declarations in the sprotty package as deprecated (they will still work, but should be changed to the new sprotty-protocol definitions at the earliest convenience).

What do you think?

[tortmayr]

👍 We are currently also evaluating the efforts of providing a node.js based GLSP server so this sounds like the perfect opportunity to align our efforts.

In GLSP we are already using a monorepo pattern similar to your suggestion and are quite happy with it. So I’m all for it. Keeping the core sprotty code and application specific glue code in separate repositories definitely makes sense. We also came to the same conclusion.

In order to keep API breakage at a minimum, we could mark the original declarations in the sprotty package as deprecated (they will still work, but should be changed to the new sprotty-protocol definitions at the earliest convenience).

Sounds good to me. However, I would only provide the deprecated API for limited time frame and the drop the support for it in a later release (similar to how it has been done in Theia with the @theia/languages AP). In our case I think we should drop the deprecated API once sprotty is leaving incubation.

[tortmayr]

Open discussion points from #233: From @spoenemann :

I’m currently working on extracting the action types and common datastructures of GLSP into a separate protocol package

@tortmayr Do you need any input / help on this?

Thanks, I think I don’t need any help for now. We have already contributed the initial PR for this. (see also (https://github.com/eclipse-glsp/glsp-client/tree/master/packages/protocol/src/action-protocol)) Currently we are duplicating/re implementing the types and action definitions that we need from sprotty. As soon as the new sprotty-protocol package is available we will remove the duplicate code and directly reuse the new package.

Note that I’ve already created an example of a Sprotty server in Node.js: https://github.com/litanlitudan/mlir-hlo-sprotty-vscode/tree/master/src/sprotty-node

Thanks! I already saw that, and it was very helpful as a reference!

I planned the 0.11.0 release that includes the monorepo restructuring for November 11: https://projects.eclipse.org/projects/ecd.sprotty/releases/0.11.0

Does that match your plans, or is it too early?

Great, sounds good to me and perfectly aligns with the GLSP plans

@tortmayr an important constraint on this: We should “block” all development while working on the restructuring to avoid unnecessary work for copying changes / resolving conflicts. In particular, there is a PR that needs to be reviewed and merged: #245

Agreed.