3 ms·

We are using a monorepo with inside 20-30 services and 3-6 native apps (lost the exact count). We have a folder for each service or reusable library. /android (

We are using a monorepo with inside 20-30 services and 3-6 native apps (lost the exact count). We have a folder for each service or reusable library. /android (a native android app wrapping the webpapp) /app (SPA webapp) /api (REST apis) /blog /docs /graphql /ios (a native iOS app wrapping the webpapp) /www (landing pages) One tip I can give you is to flat the structure and avoid nesting as much as possible. For example might be better to place the custom_plugins in the root rather than inside company_name_cms_name. Few folders that I believe are not necessary are things like /src (everything is freaking source code). It's better to have one more folder at the root where is visible by scrolling the Project Tree than having a nested folder than is not visible until the parent folder is expanded.

bredren 6y ago
Thank you for the specific feedback and general. One thing I noticed is you do not include the framework in the folder name. I may have fallen out of favor, but a while back it seemed like repos would be named in part by their tech. I.e. product_name_django. A quick look at trending projects in python and swift on github seems to confirm that. [0] It seems like you give top level naming to services and to entire applications. Is there anything other than memory or doc with indicating meta to quickly discern what is what? db48x commented on a top-level doc like this, do you use something like that? Perhaps a readme provides this? Can you tell me anything about issues / tickets? For example, I commonly use github issues on a per-repo basis, on some projects that's a problem because they go together. However on a monorepo like you've described, perhaps a lot of tagging would be needed to classify what goes to what. I'm interested in how you issues up to commits, and have effective milestones filled with these issues. [0] https://github.com/trending/swift https://github.com/trending/swift, https://github.com/trending/python https://github.com/trending/python For example, you might see repos that
- db48x 6y ago
  The advantage of a monorepo over a lot of smaller repositories is that you can make changes across your entire codebase at once. A new feature might involve adding a new api in /api, and updating the mobile apss in /android and /ios, as well as the webapp in /app. You might also mention the feature in the documentation (/docs), as well as the website in /www, and so on. All of those changes happen as part of a single merge to master (or whatever branch system you prefer) and are discussed in a single issue. Simplicity is the whole point, so you just assign the whole issue to a milestone and you're done.
  - bredren 6y ago
    Got it. Thank you again for the feedback.

bredren 6y ago

Thank you for the specific feedback and general. One thing I noticed is you do not include the framework in the folder name. I may have fallen out of favor, but a while back it seemed like repos would be named in part by their tech. I.e. product_name_django. A quick look at trending projects in python and swift on github seems to confirm that. [0] It seems like you give top level naming to services and to entire applications. Is there anything other than memory or doc with indicating meta to quickly discern what is what? db48x commented on a top-level doc like this, do you use something like that? Perhaps a readme provides this? Can you tell me anything about issues / tickets? For example, I commonly use github issues on a per-repo basis, on some projects that's a problem because they go together. However on a monorepo like you've described, perhaps a lot of tagging would be needed to classify what goes to what. I'm interested in how you issues up to commits, and have effective milestones filled with these issues. [0] https://github.com/trending/swift https://github.com/trending/swift, https://github.com/trending/python https://github.com/trending/python For example, you might see repos that

db48x 6y ago
The advantage of a monorepo over a lot of smaller repositories is that you can make changes across your entire codebase at once. A new feature might involve adding a new api in /api, and updating the mobile apss in /android and /ios, as well as the webapp in /app. You might also mention the feature in the documentation (/docs), as well as the website in /www, and so on. All of those changes happen as part of a single merge to master (or whatever branch system you prefer) and are discussed in a single issue. Simplicity is the whole point, so you just assign the whole issue to a milestone and you're done.
- bredren 6y ago
  Got it. Thank you again for the feedback.