The third option is to stop splitting: put BookNest, the admin site and booknest-ui in one monorepo, and share the library through npm 2,036 workspaces (MERN Stack Development, Node.js) or a tool such as Nx 180,159 or Turborepo 226,392 . A change across projects is then one commit, at the cost of a larger repository (Large Files and Big Repos).
| Question | Submodule | Subtree | Monorepo |
|---|---|---|---|
| What is stored | A commit pointer | A copy of the files | Everything, once |
| Plain git clone works | No, needs --init | Yes | Yes |
| Pinning a version | Exact, by commit | By merge, with --squash | Not needed |
| Sending changes back | Commit inside, push | git subtree push | Just commit |
| Main risk | Stale or missing checkouts | Split is slow, merges noisy | Size, access control |
Choose a submodule for a large project with its own releases that must be pinned by exact commit, such as a vendored C library. Choose a subtree when consumers mostly read the shared code and want a plain clone to work, which is BookNest's case: the subtree stays. Choose a monorepo when one team changes the projects together. And where a package ecosystem exists, a versioned package (Package Managers) is often simpler than all three.