HACKER Q&A
📣 bredren

Monorepo design best practices? (naming convention etc.)


I need to create a company's first repository.

It will immediately cover custom plugins to use with the existing site built with an off-the-shelf CMS and commercial plugins.

Eventually, it is likely the entire site will be replaced with a custom web application and mobile clients.

Rather than discuss the merits of a monorepo, I'm looking for direct implementation recommendations.

What is an appropriate folder naming appropriate for top-level and secondary level? i.e.

Presuming the company name is largely the product name:

Repo path for new custom plugins

  [org_name]/[company_name_cms_name?]/[custom_plugins?]/ [custom_plugin_name?]/
New Custom web application:

  [org_name]/[main website? web_application? company_name.com?]/[company_name_[framework_name]]?
Mobile client

  [org_name]/[company_name_framework]?

  👤 giorgioz Accepted Answer ✓
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.
👤 db48x
No naming scheme will be perfect. What you really need is a top–level document that describes what is inside each directory, and how they relate to each other. In prose, with paragraphs, headings, links, and a table of contents. Use something like asciidoctor, markdown, or org-mode so that you have something that is readable in the terminal and can also be exported to HTML.
👤 jjgreen
I'd keep the bottom level for repo-maintainence, so bin/ etc/ share/ for executables, configuration etc (if Unix is your thing, or some other pattern), then pkg/ for the per-plugin directories