weekday - Moses Yebei

The Problem

Teams that rely on Google Calendar or Notion often hit friction when trying to embed calendar data in custom workflows or add AI‑driven assistants. The proprietary APIs limit UI customisation and lock you into vendor‑specific authentication flows.

What This Does

weekday is a self‑hosted calendar UI built with Next.js, tRPC, and Drizzle ORM. The core Google‑Calendar client lives in packages/google-calendar/src/ (e.g., client.ts, resources/calendars/events.ts). UI components such as the month view (apps/web/components/event-calendar/views/month-view.tsx) and AI chat helpers (apps/web/components/ai/*.tsx) render events and let users create, edit, or delete them via the Google Calendar API. Authentication is provided by packages/auth/index.ts (Better Auth) and the data layer by packages/db (PostgreSQL schema in drizzle/schema.ts).

How It Is Wired

Execution starts in the Next.js server entry apps/web/trpc/server.ts, which registers tRPC routers from packages/api/src/routers/*.ts. The primary router (api.ts) exposes endpoints like GET /api/trpc/calendar.list. A request hits packages/api/src/routers/calendar.ts, which calls the Google client:

createGoogleCalendarClient -> packages/google-calendar/src/client.ts (constructor)

From there, client.ts delegates to resource modules, e.g.:

packages/google-calendar/src/resources/calendars/events.ts – defines list, create, update, delete.
packages/google-calendar/src/resources/calendars/acl.ts – ACL helpers.

The most‑used internal function is cn in apps/web/lib/utils.ts (called from 43 files). The hub module packages/google-calendar/src/internal/request-options.ts is imported by 12 other modules, making it a high‑blast‑radius point.

The import graph contains 19 circular dependencies (e.g., client.ts ↔ core/api-promise.ts ↔ core/resource.ts), which inflate the cognitive load and increase risk when refactoring. Several files exceed 800 lines (client.ts, events.ts, event-dialog.tsx), and deep nesting (up to 9 levels) appears in month-view.tsx and chat tools. These patterns mean a change in one of the hub modules or oversized files can ripple through many components.

Database interaction occurs in packages/auth/index.ts (e.g., this.db.query.account.findFirst) and via the Drizzle ORM in packages/db. The only external side‑effect traced from an entry point is a call chain that eventually reaches the database through methodRequest → request → makeRequestWithRefresh → refreshTokenIfNeeded → getGoogleAccount.

How To Use It

# Clone the fork that this briefing targets
git clone https://github.com/moses-y/weekday.git
cd weekday

# Install (Bun is recommended; npm works as well)
bun install

# Copy environment template and fill required values
cp .env.example .env
# edit .env – set DATABASE_URL, AUTH_SECRET, GOOGLE_CLIENT_ID/SECRET, AI_API_KEY, etc.

# Initialise the PostgreSQL schema
bun run db:push   # defined in package.json scripts

# Start the dev server
bun run dev

A Docker alternative is provided:

docker compose up --build

The docker-compose.yml builds the Next.js app and a PostgreSQL container, using the same .env variables.

Real‑World Use

An internal tool can embed the Weekday UI in an intranet portal, allowing employees to schedule meetings through the familiar Google Calendar flow while an AI assistant (via packages/google-calendar and apps/web/components/ai) suggests optimal times based on free‑slot queries (get-free-slots.tsx). The tRPC API lets other services fetch calendar data without exposing Google credentials directly.

Code Health & Issues

High – Dependency advisory: next@16.1.6 has CVE‑2026‑44575. Upgrade to the fixed version and commit a lockfile.
High – No test suite: 170 source files, zero test files. Add unit/integration tests for each public entry point.
High – No CI pipeline: No .github/workflows or other CI config. Introduce a GitHub Actions workflow that runs bun install, bun run build, and the test suite.
High – No build gate for Docker: docker‑compose.yml is never validated. Add a workflow that builds the image and runs a health check.
Medium – Missing Dependabot: No auto‑updates for the 8 manifest files. Add .github/dependabot.yml.
Low – Missing repo conventions: No .editorconfig, .gitattributes, or formatter config. Add those to enforce consistent line endings and style.
High – Import cycles: 19 modules in circular imports (e.g., client.ts, core/api-promise.ts, core/resource.ts). Break cycles by extracting shared types or using lazy imports.
High – Oversized files: client.ts (827 LOC) and event-dialog.tsx are hard to maintain; split by responsibility.
High – Deep nesting: Max indentation depth of 9 in several UI components; refactor with early returns or extracted helpers.
High – Duplicated code: Repeated 6‑line blocks across 23 files; consolidate into shared utilities.

The Bottom Line

weekday delivers a functional, AI‑enhanced calendar UI that can be self‑hosted and extended via a clear tRPC API. The codebase is usable but suffers from import cycles, large monolithic files, and a lack of automated testing and CI. It is suitable for teams comfortable refactoring TypeScript monorepos and willing to invest in test and CI scaffolding before production use.

What the analyser found

Deployment readiness

4/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

204 files

TypeScript83
TSX82
JSON19
JavaScript5
Markdown3
SQL2

ReactNext.jsDocker

Module dependencies

The 10 most depended-upon modules of 170, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_src_internal_request_options["request-options"] n1_alendar_src_core_api_promise["api-promise"] n2_e_calendar_src_core_resource["resource"] n3_alendar_src_internal_headers["headers"] n4_s_google_calendar_src_client["client"] n5_ogle_calendar_src_core_error["error"] n6__src_resources_calendars_acl["acl"] n7_ndar_src_internal_utils_path["path"] n8_r_src_internal_builtin_types["builtin-types"] n9_packages_api_src_trpc["trpc"] n4_s_google_calendar_src_client --> n1_alendar_src_core_api_promise n4_s_google_calendar_src_client --> n5_ogle_calendar_src_core_error n4_s_google_calendar_src_client --> n8_r_src_internal_builtin_types n4_s_google_calendar_src_client --> n3_alendar_src_internal_headers n4_s_google_calendar_src_client --> n0_src_internal_request_options n1_alendar_src_core_api_promise --> n4_s_google_calendar_src_client n2_e_calendar_src_core_resource --> n4_s_google_calendar_src_client n0_src_internal_request_options --> n3_alendar_src_internal_headers n0_src_internal_request_options --> n8_r_src_internal_builtin_types n7_ndar_src_internal_utils_path --> n5_ogle_calendar_src_core_error n6__src_resources_calendars_acl --> n1_alendar_src_core_api_promise n6__src_resources_calendars_acl --> n2_e_calendar_src_core_resource n6__src_resources_calendars_acl --> n3_alendar_src_internal_headers n6__src_resources_calendars_acl --> n0_src_internal_request_options n6__src_resources_calendars_acl --> n7_ndar_src_internal_utils_path classDef cyc stroke:#ef4444,stroke-width:2px; class n1_alendar_src_core_api_promise,n2_e_calendar_src_core_resource,n4_s_google_calendar_src_client,n6__src_resources_calendars_acl cyc;

Dependencies

19 of 87 declared dependencies are a major version behind. Resolved 81 of 87 against the registry.

Package	Declared	Latest	Behind
`@types/node`	^20.14.10	26.2.0	6 major
`uuid`	^11.1.0	14.0.1	3 major
`dotenv-cli`	^8.0.0	11.0.0	3 major
`typescript`	^5.8.2	7.0.2	2 major
`@ai-sdk/anthropic`	^3.0.37	4.0.39	1 major
`@ai-sdk/google`	^3.0.21	4.0.44	1 major
`@ai-sdk/openai`	^3.0.25	4.0.42	1 major
`@ai-sdk/react`	^3.0.75	4.0.69	1 major

Findings

MediumNo test files detected - untested code paths repository-wide
MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config
LowDependencies declared without a lockfile - non-reproducible builds apps/web/package.json

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high4

medium1

low1

Upgrade the pinned dependency carrying a published advisoryhigh28 occurrences

next@16.1.6 CVE-2026-44575 (high) +27 more

The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Add a test suite; this repository has nonehigh170 occurrences

170 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Add a workflow that builds and tests this repositoryhigh

170 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Add a build gate for the deployable artifacts herehigh

docker-compose.yml

deployment artifacts with no workflow

Something in the repo is meant to reach a server and no automated step has ever validated it, which is the state of 125 repositories here.

Fix: Add a workflow that at least builds the image and validates the manifests.

Enable Dependabot or Renovatemedium

8 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.