Monorepo 2023

Monorepo 2023

  • Purpose and outline
  • Layout
  • Core packages
    • metastore (and its api)
  • Relation to Portal.JS
  • Target for creating something with monorepo (or refactoring something existing)

SCQH

Subject: creating a monorepo

Question: should we create a monorepo and why?

Answer: we want to consolidate all development both of products and client "apps" (including custom frontends) into one monorepo

The suggestion is to consolidate these different "apps" into a single monorepo for easiest maintenance.

  • clarity:
  • keeps things in sync especially re core packages:
  • easier to start: we have clear templates/examples in one place

Situation:

  • we deploy customized "frontends" (usually based on "portal.js") and these have a shared set of components (aka portal.js)
  • these frontends often use traditional ckan backend
  • plus build off a standard template (or templates) - currently the portaljs ckan example (??)
  • Once an app is created it needs to be maintained and evolved.
  • today where we boot a new repo for every client.

Complication

What is the layout

packages/
  core
examples/
apps/
  client apps etc

What is the API for the query layer

Concern - initial discussion

  • We are joining all our projects in one repo
  • What is actually shared?
  • portal.js is using react 17 rather than react 18
    • we use --force because it is using react 17
    • whilst new projects use react 18
  • Portal.JS we started building and then stopped maintaining
    • so every time … we start again

=> we aren't maintaining portal.js and we should!

Built with DataHub LogoDataHub Cloud