[REFACTOR] Setup Turborepo for Monorepo architecture

[github-actions]

Problem Statement

As we add more scripts, a Discord bot, or shared UI components, keeping everything in a single Next.js root directory will become messy.

Proposed Solution

Migrate the repository to a Turborepo workspace. Move the Next.js app to apps/web and create shared packages in packages/ui and packages/config.

Alternatives Considered

Nx, but Turborepo is generally easier to set up for Next.js-heavy codebases.

Additional Context

This is a major structural change. Ensure all Vercel/Cloudflare build configurations are updated to point to apps/web.

[SakethSumanBathini]

Hey @PRODHOSH Can i work on this issue can you assign me this issue please ??

[PRODHOSH]

go ahead @SakethSumanBathini

[SakethSumanBathini]

I picked this one up, then spent a while convincing myself it was a good idea right now, and I
don't think it is. Putting the reasoning here rather than quietly sitting on it, because I think
it's the right change at the wrong moment rather than a wrong change.

1. There's nothing to split yet.

The premise is future-tense — "as we add more scripts, a Discord bot, or shared UI components".
None of those exist today: one package.json, no workspaces, no second app. Turborepo's value is
orchestrating and caching tasks across packages; with exactly one package there's nothing to
orchestrate and nothing to cache against. What we'd get today is turbo.json, a workspace
manifest, a packages/config holding a tsconfig, and a packages/ui holding nothing — the shape
of a monorepo without a monorepo in it. The moment there's a real second consumer (the Discord
bot is the obvious one), the same change pays for itself immediately.

2. It would break every open PR in the repo, including four that aren't mine.

Moving the app into apps/web renames every path in the tree. Git handles that fine on main,
but it makes every in-flight branch unmergeable — every one of the 8 open PRs right now touches a
file that would move:

• feat: markdown export #425, Feat/ automated thank you message #426, feat: Filter PRs by status in LatestMergedPRs #427 (@Aditya8369)
• fix: improve contrast of unselected year buttons in dark mode #344 (@HoussemEddineChaouch)
• fix: make server-computed profile columns unwritable from the client (Closes #409) #435, refactor: move design tokens into @theme so Tailwind v4 generates utilities (Closes #414) #436, feat: add an achievements grid with earned and in-progress milestones (Closes #396) #437, feat: rate limit the refresh endpoint per IP (Closes #408) #438 (mine)

Four of those belong to other contributors who'd have to rebase across a full tree move through no
fault of their own. That's a bad thing to hand someone, and it's the part I keep coming back to.

3. The deployment surface is the risky bit, and it's the hardest part to prove in a PR.

The issue notes it itself — Vercel/Cloudflare root directories have to be repointed at apps/web.
This project builds via @opennextjs/cloudflare, so that's a real config change that can't be
validated from inside a fork PR: CI will happily go green on a build that then fails to deploy.
That's a change that wants a maintainer's hands on the deployment settings at merge time, not a
contributor's PR discovering it afterwards.

What I'd suggest instead

Do it when both are true: the PR queue is drained (so nobody eats a rebase), and there's an actual
second package to extract. At that point it's a mechanical, low-drama change with a clear payoff,
and it's ideally landed as a maintainer PR with a brief merge freeze rather than a contributor
branch racing seven others.

Happy to take it then, and happy to be overruled if you'd rather do it now — but I'd rather flag
the cost than quietly hand you a PR that breaks four other people's work. Unassigning myself so
it isn't blocked on me in the meantime.

[PRODHOSH]

Thanks for looking into this and sharing the detailed reasoning. I agree that this is a good change, but not the right time. We'll revisit this once we have multiple packages or shared modules that actually benefit from a monorepo setup. Closing this for now, and we can reopen it when the need comes up.