[question] Make Cylc UI a monorepo project

[kinow]

Describe exactly what you would like to see in an upcoming release

In JS, monorepos are quite popular. These are repositories that contain a JS application or library, with other related sub-projects (normally smaller libraries or components) in the same git repository.

Examples of such projects:

• vuejs/vue: https://github.com/vuejs/vue
• vuetifyjs/vuetify: https://github.com/vuetifyjs/vuetify
• facebook/react: https://github.com/facebook/react
• vuejs/vuepress: https://github.com/vuejs/vuepress
• jupyterlab/jupyterlab: https://github.com/jupyterlab/jupyterlab/
• jupyterlab/lumino: https://github.com/jupyterlab/lumino

Additional context

I don't think we need this now. We can look into this later, near 1.0 release. Preferably after others have got familiar with the build & code base.

IMO, these are some of the pros:

• We could isolate the dependencies
  • We have 34 dependencies in production (npm ls --only=dev --depth=0 | wc -l), and 39 in development (npm ls --only=dev --depth=0 | wc -l). But many of these dependencies have a specific use case, such as graphql, which should be used by the WorkflowService, or the upcoming infinite-tree used by the new Tree component. At the moment, these dependencies are added to the whole project. With the multi modules, we could isolate where the dependencies reside.
  • Isolating the dependencies has an extra advantage of preventing accidental uses of dependency code. For example, the infinite-tree code shouldn't be used in the Graph component
• We could start migrating parts of the project to TypeScript
  • With these sub-projects, it would be easier to choose a small one to experiment with TypeScript
• Writing tests would be easier
  • The tests that we have spread over multiple views and components. With the sub-projects, the tests would reside and each individual project.
• Code re-use
  • This is my main reason for this proposal. If a developer decides to create an R Shiny widget, or a JupyterLab widget, that displays the Cylc graph or Cylc tree using JSON, for example, s/he could simply import { Tree } from @cylc/tree-component or import { Graph } from @cylc/graph-component. And that would give the exact same output as Cylc UI (as specified in package.json). Allowing users/developers/researchers to reproduce what they have in their workflows and create notebooks to share/publish/etc.
  • But I have a fork of Cylc UI where I am planning to maintain a copy of the components and later release under my own user space in NPM and have fun trying to create a widget in my spare time. So this is not really necessary I think, just would be nice.

But there are cons as well:

• The project build would get more complex
• We would have to move to Yarn (Migrate to Yarn? #364) and adopt Lerna (although there are alternatives for NPM, none is well supported right now)
• There are issues when different sub-projects have different library versions.
• Maintaining dependencies is harder with monorepos

Some links for references:

• https://hackernoon.com/4-ways-to-go-monorepo-in-2019-ea5d19fc1f08
• https://leerob.io/blog/monorepo-lerna-yarn-workspaces

Pull requests welcome!

[kinow]

Removed milestones as I think we may not even need it. GitLab, for example, uses plain old JS, with a single repository, and they maintain one of the largest Vue applications. I will probably just maintain a separate fork or repository with the components that I want to use 😬 but just leaving it here in case someone else ever has a similar idea or use case.

[hjoliver]

(I probably need to talk with you about this to understand it better ...)

[kinow]

(I probably need to talk with you about this to understand it better ...)

Sure. But not really important. Just an option for later when the project is more stable and probably a bit larger.

[oliver-sanders]

This is my main reason for this proposal. If a developer decides to create an R Shiny widget, or a JupyterLab widget, that displays the Cylc graph or Cylc tree using JSON, for example, s/he could simply import { Tree } from @cylc/tree-component or import { Graph } from @cylc/graph-component

This would be useful for generating graphs in the documentation etc.