Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: monorepo #71

Closed
2 tasks done
Xhale1 opened this issue Feb 9, 2023 · 2 comments
Closed
2 tasks done

Discussion: monorepo #71

Xhale1 opened this issue Feb 9, 2023 · 2 comments

Comments

@Xhale1
Copy link
Contributor

Xhale1 commented Feb 9, 2023

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.

@climba03003
Copy link
Member

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

@Eomm
Copy link
Member

Eomm commented Feb 9, 2023

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.

@Eomm Eomm closed this as not planned Won't fix, can't repro, duplicate, stale May 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants