Discussion: monorepo

[Reece Carolan]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

Have we considered combining the Fastify documentation site with the main Fastify package as a monorepo?

Motivation

Currently the Fastify repo contains the documentation source, while this repo contains the website source code. This (in my opinion) adds a considerable amount of overhead and difficulty for new contributors. For example, requiring the gh utility to be installed and setup struck me as unusual for a documentation site. As the original creator of this repo it took me longer than I'd expect to get to a point where I could preview the site in my browser (admittedly I'm sure that can improve without a monorepo).

I think it would be great if the markdown for the documentation, the website source code, and the core fastify code could all be located together. It could make getting started, previewing changes, and managing PR's more streamlined.

I'm certain I'm missing something here which would present a challenge. Very curious to hear thoughts.

Example

I setup a simple (incomplete) example in one of my repos over at https://github.com/hello-pangea/color-picker. It's built using turborepo.

[KaKa]

The problem is how to get the source for different version of fastify.
gh provide a simple way but not a must.

[Manuel Spigolon]

gh provide a simple way but not a must.

Yeah, it is not mandatory - but hey, I must have fun doing OSS (and I almost forgot it), so I used it and I'm using it for checking out the PR locally.
In this case, we need just a good first issue to remove this dependence.

Have we considered combining the Fastify documentation site with the main Fastify package as a monorepo?

I think if we try to propose this, we will get a lot of NO because:

• "we don't want notification about the website" (dependabot, website features and changes)
• "the main repository becomes huge": and this is a fact. Right now, the core repo is very light
• "we ship source code, documentation and test - the website is not necessary"

I bet on it - and I quite agree with these sentences.

considerable amount of overhead and difficulty for new contributors

I know that pain, but I think this is a nice example of what you get at work: odd specifications, and you (as a developer) must do something that works 😄 So I see it as a good gym.

---

In general:

• I hate Fastify's docs setup (it is not easy to read for new devs)
• I respect all the Project Boundaries listed here because the people who wrote the documentation - set them
• I understand that to propose a breaking change, I must conquest the trust:
  • to ship the biggest challenges
  • to take ownership
  • to provide good results
  • to respect the legacy

For this reason, I took the responsibility of completing this website migration, otherwise, nobody else would see the value of dealing with all these overheads.

So, I think the monorepo is impossible and will be impossible.
The majority of the team members do not care about the website, otherwise, I think it would be nice and tidy - they care about performance and code, and this is GREAT and fine. I care about the website because I think it will help Fastify to become the next expressjs (talking about downloads 😄).

What I think is that after completing the first project migration, there will be opportunities to build the future and propose disruptive things such as:

• create git sub-module to share documentation across repositories
• drop older docs from the online website
• duplicate/sync the docs across repos
• whatever the website team will came up with to improve the website

we have so many options, but we must gain trust first.