Problem Statement
We want to implement modularized libraries in a single directory which can be used within all of the apps. Each library within that single directory (packages), will have its own tests, bundler, exports, etc.

Our libraries will also be publishable to NPM registries like npmjs.
That means any other projects can import, for example, our database library @cuhacking/db 🤩

Here is the structure of the packages directory:

2025/
├─ apps/
│ ├─ .../
├─ packages/
│ ├─ api/
│ ├─ auth/
│ ├─ config/
│ ├─ db/
│ ├─ env/
│ ├─ utils/

The benefits of going for this clean modularized approach are:

1. Code reusability: allows us to re-use library code in whichever applications necessary
2. Consistency: using a library in any applications will yield the same result.
3. Easy collaboration: when a change needs to be done for the library, it is obvious what changes are being done to the library at all times.

Goals

1. Create a few modularized libraries in the packages directory, such as api, db, env which may depend on one another
2. Fully migrate to Drizzle ORM as in issue [ADR]: migrate ORM from Prisma to Drizzle #49 and implement teams route
3. Define minimal steps to publish such as the build step and testing, without any flaky tasks
4. Deploy to and install from a local registry, using Verdaccio
5. Document the process of using, creating, modifying, & adding tests to the library

Out of Scope

• Restricting the use of certain packages in applications. For example, restricting the use of the db package instead of the api package in the portal. One solution to this restrictions would be with ESLint rules.
• Custom Nx library generator plugin which will generate new libraries with the proper configuration files, and scaffoldings.
• Documentation of the APIs as it is still a topic of discussion.

Solution Summary

History/Context
Initially, we have had our business logic in a single app. We have found that it is best to put this logic on the monorepo level to allow apps to use the logic consistently.