Monorepo dilemma: Where do you store your common business logics?

Question

In my current monorepo structure for frontend, this is how it looks:

• apps\

  • jira\

  • confljuence\

• packages

  • ui

  • utils\src (contains common utils like useDebounce.ts, isEmptyObject.ts, etc.)

From what i have seen in most monorepo examples(open source) people put only non business logic stuff in utils package. I need to share a piece of code (constants object) between Jira and confluence app. Please note that this constant is a business logic constant (mapping of some api response value to enum). What would be the best location to keep this ? Should i create a new package or keep it in utils or duplicate it at both apps ? Also please note that my real monorepo is a really large codebase and contains tons of files.

Thank you in advance fellow devs !!

Answer 1

When I understand this correctly, you have two different apps, and all shared code betwen them needs to be located in one of the packages. Currently, all of the shared code can be classified as "ui" or "utils", and now you have some code to share which does not fit into those two categories. If that is correct, it should be obvious that the most natural solution would be to introduce a third category/package.

How you call that package (maybe just "bl", maybe "apimapppings) is up to you and should be made with some foresight of more common code in the future. The crucial point here is, however, to use package names which identify strictly disjoint categories, so it stays mostly obvious for the team which kind of code can be found where.

With this in mind, I would recommend to revisit your "utils" package from time to time. "utils" is not a descriptive name, typically used as a catch phrase for code where people currently do not have a better idea for a common name.

When that package grows up to a certain size, it may become troublesome to check if a certain solution for a certain problem already exists in your codebase. Maybe there is more code in "utils" which better belongs to "apimappings", maybe there is code which could be grouped together under a more sensible name like "mymath", or "domprocessing", or whatever you can find in your codebase.

Whenever you find more than 3 or 4 functions, classes or modules inside your utils package which might be grouped together, consider to refactor* them into a new package with a better name. That will enhance the rediscoverability of existing code heavily.

_{*Of course, constant refactoring is something which I would only recommend with typechecking and automated tests in place.}

Recommended reads:

• Is a common library a good idea?

• Semantically more appropriate package name than `util` for the following things?

• What are the problems with a relatively large common library?