Proposal - Move pages out of mono repository into team owned repositories.

[matthewhardern]

I am opening up for discussion moving pages from the mono repository organisms directory into repositories owned by the pages team. Such a move would enable teams to own their own pages and keep this repo as shared components only. I also suggest that we have a template repository for these pages to act as a starter for new pages to encourage best practices.

[ashleynolan]

Just to keep track of a discussion we had on another platform:

@lsphillips
I don't know if I should ask it here or add it to the discussion, but what value is there in adding pages to a shared components repository?

I don't think we should be aiming for constant backward compatibility, otherwise, components can never cleanly move forward. If I'm making a breaking change to a component, it sounds like I have to fix the page that may be broken. To be honest this upgrade process should be done by the owning team when they actively upgrade the package version.

Having really complex organisms like this involved makes the process of pushing simple component changes really slow.
I think there should be a clear separation of a library of reusable tools and components and the applications that utilize said library.

---

@ashleynolan
I'm kind of in the middle on this atm – I wouldn't want each page to all be in separate repos (because from experience, those repo's get very out of date in terms of the components it uses – i.e. vertical team shared UI tools/components which get very out-of-date).

I definitely agree that making a breaking change to a component shouldn't mean you need to fix all the pages using that component – but as far as I'm aware, that's not the case atm (you still need to update the pages separately after publishing the change to a component like a button or form-field for instance.

I think the only potential for slowing down component changes comes from the bottleneck of having all PRs and the build on the same repo (so there's more potential for waiting for build agents and having to rebase master when PR-ing).

I think pulling out page components makes sense for sure in some way – the two choices are either to pull it out as a separate folder (as Matt mentions) or to pull them out as a separate mono-repo of page components – that way we can try to ensure that all of the shared page views are on the same set of dependencies for instance. I think there are potentially pros/cons to both really so it just depends on how we want to structure it.

I think it'd be worth moving the pages to a separate folder for sure (as that'll be much quicker from an engineering perspective) and then if we find we're having issues with that approach we can put the extra effort into moving them out into their own repo. I would think having it in a separate folder may mean we could split the build potentially on CircleCI too down the line, which may help with that issue.

---

@lsphillips
Fair enough. I'd say these two statements contradict each other:

because from experience, those repo's get very out of date in terms of the components it uses – i.e. vertical team shared UI tools/components which get very out-of-date"

and

but as far as I'm aware, that's not the case atm (you still need to update the pages separately after publishing the change to a component like a button or form-field for instance

If we don't have tests break when making a breaking change for pages, you will still run the risk of pages being wildly out of date if it's still going to be the primary concern of the owning team.

I think having a separate mono repo for the pages would be the best goal to aim for, for sure 🙂

---

@ashleynolan
Yeh, I can see what you mean. Keeping them in the main mono-repo doesn't mean that they'll be any more up to date for sure – I guess it just means it's a bit harder to ignore 😆

I know the issue of how to ensure teams keep these 'page' components up-to-date with the core component changes has come up quite a few times, so I think it's something we need to work out how best to communicate out and keep on top of.

@matthewhardern I think, for now, moving them to a separate folder makes sense, and then it's probably worth us starting to work out the work involved if we were to want to move them out to their own mono-repo in the future (setting up separate CI, how we ensure config is consistent between the repo's etc) and making a list of pro's/cons for both approaches

[tommcclean]

+1, I think using a template repository would help to...

• Start each teams repo off on an equal footing (with the advancements we have made such as visual reg) and mean it would be easy for people to jump between them in the rare cases they would need to
• While giving the teams the autonomy to advance in areas they care about.
• Keeping ownership within the team (atm if feels like we own those pages, we shouldn't really)

Having them in Fozzie atm seems to be encouraging gigantic mammoth components which aren't really reusable but also bulk out the repo slowing builds down.

Also being seperate means the fact lerna is using local versions of components rather than published ones doesn't cause breakages to the pages themselves; as they would no longer be local. It also means that we don't have a single point of failure for working, and no race to merge PRs.

I think its important to distinguish between a page and an organism; as they are different things. searchbox is an organism, the checkout is a page

[ashleynolan]

At the risk of asking a stupid question – by template repository, do you just mean, a repo that has all of the page view components in? (so checkout and registration for instance atm). Just want to make sure we're on the same page in terms of definitions!

[tommcclean]

At the risk of asking a stupid question – by template repository, do you just mean, a repo that has all of the page view components in? (so checkout and registration for instance atm). Just want to make sure we're on the same page in terms of definitions!

I was thinking you copy fozzie; remove all the atoms/services/organisms etc from it and clean it; then when a team (like the checkout team) need to build pages, they fork it for their team and now they have a repo with the same capabilities as fozzie components, but that they own; then if they build a few pages they all go in there, but other teams; say Menu/accounts have their own copy.

[ashleynolan]

Ah ok – makes sense.

I think it all depends if we can keep the config in sync across these repo's if we went that route, instead of having one repo for all pages. One of the main pain points atm whenever we have to help update verticals is that dependencies like eslint (or build runners, so I guess vue-cli or vite in the future) are miles behind current, which makes changes a lot bigger than they need to be – as we're finding atm helping teams update to latest fozzie.

I think I'd favour just having a separate mono-repo for pages, rather than separate repo's for each vertical, but prob worth us spiking it out so we can see what we think are the pro's cons of both approaches.

[lsphillips]

@tommcclean

I think using a template repository would help to...

I think you should join our working group around Solutions standards, because I feel there is some cross cutting concerns there.

[siggerzz]

This is the only monorepo I've ever worked with so I haven't got too much knowledge on best practice, but to me, moving pages into another repo kind of defeats the purpose of a monorepo. Moving them into a folder within this repo makes much more sense IMO.

Looking online, there are lots of case studies from orgs with monorepos far, far bigger than ours, and they still manage to have reasonable cycle time and sense of ownership.

From a QE side, moving to another repo means another set of test config and infrastructure that we have to maintain as well as CI config. We also wouldn't want to duplicate Storybook, which means we'll have to find another mechanism to test / mock those pages in a browser.

Part of our problem at the moment is having a single CircleCI workflow for all types of change. Utilising workflows + Codeowners would go a long way, as well as some investigation into monorepo best practice.