Proposal to move CSTI's packages to this repo

[sndrs]

Following our initial conversation, this is @guardian/client-side-infra's proposed outline for moving the packages in CSNX into the dotcom-rendering repo workspace.

Please let us know what you think—your suggestions/questions/opinions will be very valuable!

Outcome

• CSTI's impact is felt directly by contributors to this repo (hopefully in a good way!)
• DCR directly consumes the packages currently in CSNX
  • changes to the packages go out to prod on dotcom/apps immediately
• packages continue to be published to NPM for use outside the workspace

Responsibilities

@guardian/client-side-infra take overall responsibility for:

• managing the workspace root (i.e. how the repo works)
• the packages currently in CSNX (source-*, libs etc)

@guardian/dotcom-platform retain overall responsibility for:

• /dotcom-rendering
• /apps-rendering

Important

As with all Guardian codebases, everyone can always propose changes to any of the code; but we're anticipating that day-to-day development for each team would settle into these areas.

How we get there

1. set up code ownership in dotcom-rendering
   • @guardian/client-side-infra will become code-owners of the repo root, but not /dotcom-rendering or /apps-rendering
   • @guardian/dotcom-platform will decide where they want the boundaries of their code-ownership to fall
2. add @guardian/prettier and consume it directly in DCR, as a proof of concept
   • it’s small, doesn’t change a lot and has no build step to delay GHA
3. add changesets to enable publishing @guardian/prettier
4. remove @guardian/prettier from CSNX
5. enable remote computation caching using Nx and apply it to @guardian/prettier package

Then take stock. If both teams are happy with how things look...

1. enable Nx computation caching for DCR and AR

Take stock again. If both teams still are happy with how things look...

1. move remaining packages from CSNX one by one, starting with source¹
2. archive CSNX

Footnotes

1. At this point, we probably also want to think about the name of the repo ↩

[mxdvl]

I think this three phases approach is very sensible, there seems to be ample opportunity to roll back if we fail to realise the monorepo promise.

As far as naming goes, my vote stands with tofu

[cemms1]

This sounds like a good approach! I also think moving prettier first is a great shout and a good one to test the waters with.

In terms of naming... it obviously shouldn't remain dotcom-rendering (and possibly shouldn't even be called that now 😶‍🌫️ )

I think a less descriptive name might have more longevity and relevance than a more specific name as we don't totally know how this repo will evolve!