gatsbyjs / gatsby

The best React-based framework with performance, scalability and security built in.
https://www.gatsbyjs.com
MIT License
55.28k stars 10.31k forks source link

Gatsby projects ( core , website , plugins ...etc ) !! #16722

Closed 3imed-jaberi closed 5 years ago

3imed-jaberi commented 5 years ago

Why all the projects are in one repository 🤔 !!

This makes the process of contributing in the site or in the gatsby core difficult locally ( cloning ...etc) .. So , dividing the project into several repositories will be better for the team and even the contributors ...

I talked to @m-allanson here #16673 about this but he didn't see that , he just closed the PR and no longer see comments.

Please @ahmedelgabri, check this with the core team ..

ahmedelgabri commented 5 years ago

@3imed-jaberi Sorry, I can't help. I'm not in the core team. Anyone who contributes to gatsby gets added to the organization. So I'm just in the organization because I contributed before.

jonniebigodes commented 5 years ago

@3imed-jaberi from a developer perspective and i'm only a contributor to this project. But i understand why this approach taken by the team. In paper it looks that the monorepo is cumbersome. But if you take a step back and take a clinical approach to it, you'll see that it's far better to maintain and reduces overhead in the codebase and also looking at the multirepo approach might look cleaner, but actually it's not as it will introduce alot of overhead for the developers as they need to be created and maintained and also there's CI configuration and maintenance and so on. I fully understand that for a person that is coming into this organization/repo it might look a bit over the top and difficult to adapt to, but it's just one of those things that you adapt sooner or later.

3imed-jaberi commented 5 years ago

@3imed-jaberi Sorry, I can't help. I'm not in the core team. Anyone who contributes to gatsby gets added to the organization. So I'm just in the organization because I contributed before.

@ahmedelgabri Thank you bro , soon someone in core team will answer me ..

3imed-jaberi commented 5 years ago

@3imed-jaberi from a developer perspective and i'm only a contributor to this project. But i understand why this approach taken by the team. In paper it looks that the monorepo is cumbersome. But if you take a step back and take a clinical approach to it, you'll see that it's far better to maintain and reduces overhead in the codebase and also looking at the multirepo approach might look cleaner, but actually it's not as it will introduce alot of overhead for the developers as they need to be created and maintained and also there's CI configuration and maintenance and so on. I fully understand that for a person that is coming into this organization/repo it might look a bit over the top and difficult to adapt to, but it's just one of those things that you adapt sooner or later.

Thanks @jonniebigodes for this reply .. I made this question in the form of a proposal for being easier to deal for contributors and even for maintainers. I understand everything about CI config. ......... but the repo realy large .

image

We can hear from other contributors and members ,maybe this will help revise this trend.

Sometimes we have to make decisions that may seem difficult, but important, that can change a lot.

sidharthachatterjee commented 5 years ago

Hey @3imed-jaberi

I'm Sid and I'm a member of the core team. Let me answer your questions one at a time.

Why all the projects are in one repository 🤔 !!

We use a monorepo to manage all Gatsby core code, documentation and official plugins. Learn more about at monorepos at https://gomonorepo.org/

This makes the process of contributing in the site or in the gatsby core difficult locally ( cloning ...etc) ..

We've seen several benefits to this approach including ease of local testing, dependency management and publishing and at the moment, the benefits outweigh the downsides (being too large to clone etc) for us.

Several open source projects (with plenty of packages) use the same approach for the same benefits (babel, react come to mind)

So , dividing the project into several repositories will be better for the team and even the contributors ...

Cloning is typically a one time process so while it might take a while, it won't be as bad after the first clone 🙂

I talked to @m-allanson here #16673 about this but he didn't see that , he just closed the PR and no longer see comments.

Apologies on Mike's behalf for missing your comment in https://github.com/gatsbyjs/gatsby/pull/16673

Hope this helps answer your questions! Thanks a tonne for raising this and taking the time to open this issue.

3imed-jaberi commented 5 years ago

Hey @3imed-jaberi

I'm Sid and I'm a member of the core team. Let me answer your questions one at a time.

Why all the projects are in one repository 🤔 !!

We use a monorepo to manage all Gatsby core code, documentation and official plugins. Learn more about at monorepos at https://gomonorepo.org/

This makes the process of contributing in the site or in the gatsby core difficult locally ( cloning ...etc) ..

We've seen several benefits to this approach including ease of local testing, dependency management and publishing and at the moment, the benefits outweigh the downsides (being too large to clone etc) for us.

Several open source projects (with plenty of packages) use the same approach for the same benefits (babel, react come to mind)

So , dividing the project into several repositories will be better for the team and even the contributors ...

Cloning is typically a one time process so while it might take a while, it won't be as bad after the first clone 🙂

I talked to @m-allanson here #16673 about this but he didn't see that , he just closed the PR and no longer see comments.

Apologies on Mike's behalf for missing your comment in #16673

Hope this helps answer your questions! Thanks a tonne for raising this and taking the time to open this issue.

@sidharthachatterjee , Thanks for this answer ❤️ ... I know about "monorepo" .. and I understand you are accustomed to this approach as a team and at the moment this is good .. (react don't rely on this approach but create-react-app do this ..).