Go to file
Corey Johnson 238df92888 Untangle Spike architecture with bridge pattern
Split the monolithic gitea/helpers.ts (which had Discord imports and created circular dependencies) into three focused libs:

1. **gitea/** — Pure API client: fetchPR, fetchReviewComments, convertUsername, threadName. No side effects or external deps.

2. **discord/** — Discord client setup: bot login, event listeners, slash commands. Now isolated from Gitea internals.

3. **bridge/** — New integration layer: webhook handler, DB mappings (Gitea PR ↔ Discord thread), Discord helpers, and createPRComment.

Dependencies now flow one direction: bridge → gitea and bridge → discord. No circular imports.

Added:
- Barrel exports (index.ts) for each lib with public API
- README.md for each lib documenting the barrel exports
- Comprehensive spike README.md with setup guide and architecture explanation
- Integration tests for webhooks (callback-based, no race conditions)
- Unit tests for pure API functions
- CLAUDE.md with links to each lib's README

This architecture makes it possible for AI to understand a lib by reading just its README, keeping context focused and small.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-03-09 15:23:11 -07:00
.github Create ci.yml 2025-07-22 16:41:56 -07:00
.vscode 🆒 2025-06-16 09:27:35 -07:00
packages Untangle Spike architecture with bridge pattern 2026-03-09 15:23:11 -07:00
.bun-version werewolf 2025-07-07 15:32:18 -07:00
.example.env revive threads 2025-07-15 14:14:07 -07:00
.gitattributes 🆒 2025-06-16 09:27:35 -07:00
.gitignore This is much better 2025-11-12 11:49:10 -08:00
bun.lock Untangle Spike architecture with bridge pattern 2026-03-09 15:23:11 -07:00
ci.ts Better naming 2025-07-22 16:29:30 -07:00
main.ts Only one proc needed 2025-11-07 15:29:27 -08:00
package.json Added cron 2025-07-25 14:15:23 -07:00
README.md Update README.md 2025-12-03 11:20:16 -08:00

Workshop Monorepo

We are making a bunch of smaller projects that occasionally rely on each other. So a monorepo makes a lot of sense! It lets us share code, and share dependencies with minimal fuss.

Ok, I want to add a new project.

  • bun init packages/WHATEVER_YOU_WANT
  • Edit the package.json and change the name to @workshop/WHATEVER_YOU_WANT

To add one of the existing packages as a dependency, edit the package.json and add it to the dependencies or devDependencies section. For example, if you want to add @workshop/WHATEVER_YOU_WANT, you would do:

{
  "dependencies": {
    "@workshop/WHATEVER_YOU_WANT": "workspace:*"
  }
}

Then run bun install and import it in your code like so:

import { something } from "@workshop/WHATEVER_YOU_WANT"

What does corey not love about this?

  • I put near-zero effort into naming things.
  • I'd prefer the namespace to be shorter, @workshop is a bit long.
  • There are lots things I don't love about nano-remix, but it works well enough for now.
  • The bun tailwind plugin doesn't work with nano-remix yet, but it looks like in a future bun release it will.

How do I run the tests?

😂😂😂😂😂