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)
- Create a demo site from an example
- https://datahub-enterprise.datopian.com is using datahub-publisher
- one of the existing production sites
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
- review portaljs-template https://github.com/datopian/portaljs-template/blob/master/lib/queries.ts
- Review metastore-lib https://github.com/datopian/metastore-lib-js and https://github.com/datopian/metastore-lib
- Portal.JS: uses graphql in the CKaN example https://github.com/datopian/portal.js/blob/main/examples/ckan/graphql/queries.ts
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
- we use
- Portal.JS we started building and then stopped maintaining
- so every time … we start again
=> we aren't maintaining portal.js and we should!