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 !!

1 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:

  • Sure that helps! Thanks. Commented Dec 27, 2023 at 11:40
  • Also one more thing, what do you think of code duplication ? Say in app A i have an api response of structure: interface ApiA { managers: object[] } and in app B a different api but same structure: interface ApiB { managers: object[] }. These 2 apis are served from 2 different backend microservices but response strucure is same (for now atleast). Would it be alright to duplicate the types for both the apps or should i move to a common package ? Commented Dec 27, 2023 at 12:02
  • 1
    "2 apis from 2 different backend microservices" sounds like those APIs look equal by chance, and not intentionally, in which case duplicate code is usually preferable over the coupling one gets by reuse. You have to use your best judgement - do you expect the APIs to change indepently from each other? Or would it be an error if one of the APIs is changed, but the other one forgotten?
    – Doc Brown
    Commented Dec 27, 2023 at 12:24
  • They are actually querying the same database and same db queries. Hence the same structure of the APIs but just that few datapoints maybe eliminated from api B. Also in both pages we show different data points. Hence i think it makes sense to create a common type and then use Pick to cherrypick certain data points from the common type in both the apps Commented Dec 27, 2023 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.