Very well done article didn't think of using @commitlint config on top of husky for defining commits I will have to use that cheers (it's a good additional way to subcategorize jira tickets).
Love also that the article goes into future follow-ups.
Without going into too much detail of reasons for monorepo would be a compact dev team working on a project that has the potential to scale large quick for example skipthedishes (delivery team, customer ordering team, UI/UX team, BE team...). If your trying to run the CICD on multiple repos and then there is a issue on one of the repos that you don't have access to on a friday night, that could be a huge problem that could of been simply resolved from having a monorepo. You include temporary locks within the user repo by default so they don't accidentally do any changes they shouldn't do on a work week and only allow changes of a file during deploy stage to production when a error occurs.
Another reason why for monorepo I think would be security having centralized info to significantly reduce the chance of a backdoor to access. If your seperating your concerns in a monorepo it can be very powerful but ultimately it depends on the business case for the product.
I do work with different styles of monorepos for a few different clients and the one thing I absolutely always find is that a lot of the challenges end up really distilling down to business and organizational decisions rather than technical ones.
It's a balance between the convenience of having a central source of truth on versioning and maintaining separation of the individual packages/apps that sometimes developers can be contracted to contribute to but are not meant to have visibility on the larger ecosystem.
I will say that the idea of file locks on specific parts of the monorepo is new to me, do you have any more info or sources on that? My practice recently has been to handle those pieces as git submodules so that devs can be given specific access to those pieces individually and project leads can manage the monorepo, but of course submodules come with their own set of challenges.
Either way I appreciate the detailed response. Cheers.
Personally I haven't done file locks and am not too familiar i think with GitHub enterprise you could use git LFS but I was thinking initially to set authorization through a seperate PSQL prisma model database instance on either locally generated with LFS or online to check within the husky file (will probably be years till i get there).
Just looking at Apollo graphql fed and having subgraphs/schemas and gateway to have separation of concerns is pretty cool for performance while still having that monrepo feel. Still in the monorepo realm but what apollo fed has to offer is going to become interesting. especially when you have one graph it can't become performant for the certain graphs you need from the start.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very well done article didn't think of using @commitlint config on top of husky for defining commits I will have to use that cheers (it's a good additional way to subcategorize jira tickets).
Love also that the article goes into future follow-ups.
Without going into too much detail of reasons for monorepo would be a compact dev team working on a project that has the potential to scale large quick for example skipthedishes (delivery team, customer ordering team, UI/UX team, BE team...). If your trying to run the CICD on multiple repos and then there is a issue on one of the repos that you don't have access to on a friday night, that could be a huge problem that could of been simply resolved from having a monorepo. You include temporary locks within the user repo by default so they don't accidentally do any changes they shouldn't do on a work week and only allow changes of a file during deploy stage to production when a error occurs.
Another reason why for monorepo I think would be security having centralized info to significantly reduce the chance of a backdoor to access. If your seperating your concerns in a monorepo it can be very powerful but ultimately it depends on the business case for the product.
Nice, I totally agree..
I do work with different styles of monorepos for a few different clients and the one thing I absolutely always find is that a lot of the challenges end up really distilling down to business and organizational decisions rather than technical ones.
It's a balance between the convenience of having a central source of truth on versioning and maintaining separation of the individual packages/apps that sometimes developers can be contracted to contribute to but are not meant to have visibility on the larger ecosystem.
I will say that the idea of file locks on specific parts of the monorepo is new to me, do you have any more info or sources on that? My practice recently has been to handle those pieces as git submodules so that devs can be given specific access to those pieces individually and project leads can manage the monorepo, but of course submodules come with their own set of challenges.
Either way I appreciate the detailed response. Cheers.
Personally I haven't done file locks and am not too familiar i think with GitHub enterprise you could use git LFS but I was thinking initially to set authorization through a seperate PSQL prisma model database instance on either locally generated with LFS or online to check within the husky file (will probably be years till i get there).
Just looking at Apollo graphql fed and having subgraphs/schemas and gateway to have separation of concerns is pretty cool for performance while still having that monrepo feel. Still in the monorepo realm but what apollo fed has to offer is going to become interesting. especially when you have one graph it can't become performant for the certain graphs you need from the start.