josh/ytplayer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c5f47514ad212874bbb4bd393e4a0fc255ffd0f9
ytplayer/CLAUDE.md

9.8 KiB
Raw Blame History

ytplayer — project facts for agents

What this is

Ad-free YouTube player. Three shells share frontend/: web PWA (Bun + Hono in server/, the production deployment), Tauri (Windows), zero-native (Linux/macOS). The PWA is what runs in production; legacy/ holds the old native-only docs.

Repo map

Path What lives there
frontend/app.js The entire UI (~3.6k lines, no framework): player, playlists, search, settings, sync
frontend/sw.js + frontend/sw-update.js Service worker + update flow (FRAGILE — see below)
frontend/opfs.js / opfs-worker.js OPFS offline audio cache
frontend/fingerprint.js Browser fingerprint used as the sync key
frontend/async-guard.js Stale-async-response guard (unit-tested)
server/server.js Bun + Hono backend — endpoint list is in its header comment
server/db.js libsql schema/queries (users, profiles, video_history…)
bin/yt-dlp Downloaded by npm run setup, gitignored
scripts/ icon generation, yt-dlp setup, push helper
tests/ Playwright e2e specs · unit tests live next to sources in frontend/*.test.js
legacy/ Old native-shell docs — do not treat as current

API endpoints: GET /api/search|channel|streams|download/:id|version|user/data|profile/load, POST /api/user/sync|profile/create|profile/save, GET /sw.js (BUILD_TAG-injected), GET /* static. JSON shapes mirror the Tauri Rust bridge exactly — don't change one side alone.

Local dev

npm run setup            # download bin/yt-dlp (once)
cd server && bun install
ln -s ../frontend public # once — the server serves ONLY ./public (Docker copies frontend/ there)
bun --hot server.js      # http://localhost:3000
node --test frontend/    # unit tests (run from repo root)
npx playwright test      # e2e (see Testing below)

Local DB file: server/data/ytplayer.db (gitignored). BUILD_TAG is computed from ./public contents.

Production deployment (web PWA)

  • URL: https://worship.hesed.sbs (Traefik label in docker-compose.yml)
  • Runs on the homelab Dokploy remote node; control plane is Dokploy on the VPS (193.160.119.172, API key in ~/development/.secrets/dokploy-api.env).
  • Compose ID: wprYCM8T51f7JtSHb983p (project ytplayer, env production).
  • Pushing to git does NOT deploy. Trigger explicitly (build ≈ 5–6 min): 
    ssh -i ~/.ssh/tmp_vps/dokploy_session root@193.160.119.172 \
  "curl -s -X POST -H 'x-api-key: $KEY' -H 'Content-Type: application/json' \
   -d '{\"composeId\":\"wprYCM8T51f7JtSHb983p\"}' http://localhost:3000/api/compose.deploy"
# poll composeStatus via /api/compose.one?composeId=... until done|error
  • Confirm the deploy landed: curl https://worship.hesed.sbs/api/version — the buildTag (content hash of every file under ./public) must change.
  • Homelab node is NOT always reachable on LAN; SSH via the VPS hop: ssh root@193.160.119.172 → ssh root@10.8.0.2 (WireGuard). Container name: ytplayer-main-1dihzn-ytplayer-1. DB: libsql file /app/data/ytplayer.db (query with docker exec <c> bun -e '...' using @libsql/client).

Update-flow architecture (fragile — read before touching)

  • GET /sw.js is served by the server with the real BUILD_TAG injected by regex over the fallback expression in frontend/sw.js. Never switch back to an exact-string replace: when the fallback literal was bumped (v1.0.3→v1.0.4) the exact match silently failed, the SW version froze, and no client ever received another update while /api/version kept announcing one — the "Update available keeps showing" bug.
  • BUILD_TAG hashes every file under ./public recursively. Don't reduce it to a file subset; a change to an unlisted shell file would stop busting caches.
  • The update banner only shows when a waiting SW exists and the page already has a controller — a first install (fresh visit, or after Settings → Force refresh unregisters) passes through waiting transiently and must not banner.
  • "Refresh UI" (frontend/sw-update.js): if no worker is waiting yet (banner came from the /api/version poll), it calls reg.update(), waits for installed, posts SKIP_WAITING, waits for controllerchange, then reloads once.

Cache layout & offline thumbnails

  • Three cache families, and the split matters on activate: the versioned shell cache ytplayer-<BUILD_TAG> is evicted on every deploy, while the utility caches ytplayer-thumbs and ytplayer-fonts are listed in UTILITY_CACHES and deliberately survive it. Adding a new utility cache means adding it there too, or it gets wiped on the next deploy.
  • Thumbnails are cache-first, not stale-while-revalidate — a given thumbnail URL is immutable, so revalidating just burns a round trip per image per launch.
  • The opaque-response trap (this silently emptied the thumb cache for months). An <img> to another origin is a no-cors request, so fetch(request) in the SW resolves to an opaque response with status === 0 — not 200. The old guard was if (r.status === 200) cache.put(...), which rejected every single thumbnail, so ytplayer-thumbs was permanently empty and offline showed broken images (measured on prod: 0 entries after browsing pages full of visible thumbs). Fix in thumbnail(): re-issue the request in cors mode — ytimg/ggpht all send Access-Control-Allow-Origin: * — and cache that readable response; an opaque one is accepted only as a last resort. Never reintroduce a bare status === 200 check on a cross-origin subresource.
  • Thumbnail hosts live in THUMB_HOSTS. An unlisted host doesn't error — it just bypasses the cache and breaks offline, so add mirrors/avatar hosts there.
  • The thumb cache is capped at THUMB_CACHE_MAX (800, oldest-first via the insertion-ordered cache.keys()). Keep a cap: CacheStorage and the OPFS offline audio share one origin quota, and opaque entries are padded to ~7 MB each for quota accounting, so an unbounded thumb cache can evict saved audio.
  • App side (app.js): warmThumb() pulls artwork through the SW when a video is saved offline, and warmOfflineThumbs() runs a bounded launch backfill (THUMB_WARM_MAX = 400, 4 at a time) over cached ids + playlist videos so libraries saved before this fix repair themselves. Thumbnails only cache when something requests them — a device needs one online launch to get offline art.
  • staleWhileRevalidate() (fonts) must not return cached || networkFetch bare: the fetch resolves to null offline and respondWith(null) throws. It ends with || Response.error().

Data model quirks

  • Client state persists in localStorage key _ytpdata and syncs (debounced 400 ms) to POST /api/user/sync, keyed by a browser fingerprint.
  • A-B loop markers are per-song-per-playlist: stored on the playlist's own copy of the video (entry.ab = {a, b}) when playback source is that playlist; data.abMarkers[videoId] is only the fallback for non-playlist playback.
  • Online profiles (profiles table, /api/profile/*): named cross-device sync where the lowercase profile NAME is the only credential (passkey-style, by design). Client stores data.profile = {name, syncedAt}; sync is last-write-wins — push debounced on every persist(), pull on app launch when the server's updated_at is newer than the local syncedAt.
  • Profile share links: ?profile=<name> is consumed by adoptProfileFromUrl() at boot, before any rendering. It strips the param via replaceState (so a reload can't re-fire it) and confirms first when the device already has playlists/history or another profile — adopting replaces the synced slice. The name comes off the URL untrusted, hence escapeHtml() on it.
  • Empty-home playlist grid: renderHomePlaylists() swaps the branding hero in #playerPlaceholder for the user's playlists (hero is the no-playlists fallback). It is driven from the tail of renderSidebar() — not from render() — so every playlist mutation refreshes both in one place.

Testing

  • Unit: node --test frontend/*.test.js (sw, sw-update, async-guard, video-edit). The directory form node --test frontend/ fails on Node 22 with Cannot find module .../frontend — it resolves the dir as a module, not a test glob. That's the harness, not the tests.
  • E2E: npx playwright test — WebKit iPhone-12 profile against a static serve of frontend/ (needs npx playwright install webkit). A spurious update banner will make the settings-panel specs fail with #modal intercepts pointer events — that failure mode is a real app bug, not test flake. On the WSL laptop the WebKit install fails host validation (missing libgtk-4, libgstreamer*, …, needs sudo npx playwright install-deps); chromium is already downloaded, so ad-hoc rendering/offline checks can drive it directly instead.
  • Service-worker behaviour (thumb caching, offline) is only provable in a real browser: serve frontend/ statically, let the SW take control (needs a second reload), then context.setOffline(true) and assert img.naturalWidth > 0 plus the ytplayer-thumbs entry count. Asserting against the browser's own HTTP cache proves nothing — check the Cache API entry count.
  • Test records on prod use Probe */Recon * names; clean via the container DB, children (video_history) first.

Harness

Skills live in .agents/skills/ (symlinked into .claude/skills/):

  • deploy-prod — the Dokploy deploy + buildTag verification flow (manual-only; use for any "deploy"/"release" request).
  • mobile-app-ui-design — UI/UX design work on the PWA screens.

Commit rules

One changeset = one commit, single-line imperative message, no AI attribution of any kind (global rule). git push origin main pushes to both remotes.