8 commits

Author	SHA1	Message	Date
Nicolas	b4c81d820c	Cast a party's video to a Chromecast ... Implements a detailed spec (Google Cast / Chromecast integration) asking for a member to cast the party's video to a Chromecast's Default Media Receiver, with play/pause/seek shown as a remote on the sender's own screen. The spec's description of this app's architecture (one shared Emby stream per party, the server proxying 100% of Emby access) was verified directly against the real code before building anything, since it named specific existing services/routes as the integration points. A Chromecast is a new kind of client for the existing party-stream/burn relay: it can't carry the sender's httpOnly session cookie at all, so it needed its own narrow way in without weakening "the server holds the only real Emby token" the rest of the app is built around. - New CastTokenService (same shape as AuthService: in-memory Map, opaque crypto.randomUUID() keys, TTL-checked) issues a token scoped to one {partyId, userId}, standing in for that member's own EmbySession. New POST/DELETE /api/parties/:partyId/cast-token to mint/revoke one. - The 4 routes a Chromecast actually needs (party-stream/master.m3u8, party-stream/raw, burn/master.m3u8, burn/:segment) gained one small fallback (sessionForStream in index.ts): try the session cookie first, same as ever, then a castToken query param - either way the result is the same EmbySession type, so PartyStreamService/TranscodeService/ EmbyClient needed zero changes. The image/subtitle routes stay cookie-only, outside the spec's own 4-route list. - PartyService.leave() now revokes whatever cast token the leaving member held, unconditionally - a token dies the instant its owner actually leaves the party regardless of TTL or whether the client got a chance to call the explicit stop-casting route. - New client/src/cast.ts is the only module touching the CAF Sender SDK (loaded as a pinned CDN script, same pattern as hls.js/socket.io) - exposes a small PlaybackDriver interface (currentTime/paused/play/ pause) with two implementations, one over the local <video>, one over CAF's RemotePlayer/RemotePlayerController. This was the only new abstraction the feature needed, not a new sync mechanism: Player.ts's existing sendLocalState/applyRemoteState already read and write "the player" in one place each, so pointing them at whichever driver is active carried the host-only gate, drift-tolerance reconciliation, and 3s heartbeat over unchanged. Seek was already "the host's next broadcast" with no separate event, so seeking on the TV is party-wide for free; a non-host caster already only ever received state, so redirecting that to the cast driver reproduces "still dependent on the host" automatically. - Cast button in the player's action bar, shown to any member (not just the host) once cast.framework reports a receiver on the network. Starting a cast tears down the local hls.js instance; ending one (user-stopped, or the receiver dropping off on its own) resyncs local playback via the same loadVideo path an audio/quality change already uses. A real reload for any other reason (item change, burn-in/ subtitle/stream-options change) simply ends an active cast first, rather than keeping a live session in sync with every kind of party transition - not worth the complexity for v1. Scoped to video parties only - the spec's every concrete reference is video-specific, and MusicBar.ts has no comparable control surface today. Tests: CastTokenService (issue/resolve/reissue-invalidates-the-old-one/ revoke/wrong-party-rejection), PartyService.leave()'s new call. Full typecheck/test/build clean on both projects (115/115 server tests). Confirmed against the real running server that the 4 streaming routes still reject a request with no auth exactly as before, and now also reject an invalid castToken - both a plain 401, no regression. Confirmed in a real browser that the Cast SDK loads and initializes correctly. Not verified: no real Chromecast or Emby login credentials in this environment to take a cast session, or the button's own live behavior, any further - see docs/architecture.md's "Casting to a Chromecast" section. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-15 10:13:12 +02:00
Nicolas	4efcd67fb3	Sync text subtitle choice too, and fix an empty audio option ... Bug report: watch party members still didn't have synced subtitle settings, and the audio/language selector showed an empty choice on first load. Text subtitles were the gap left by the previous "one shared stream per party" change: that made audio/quality/burn-in host-only and party-wide, but a plain text subtitle pick (the common case - burn-in only applies to bitmap PGS/VobSub/DVB tracks) was still each viewer's own local <track> choice. Once people actually watched together, "everyone but me changed the subtitle" read as broken sync. Fixed with a parallel mechanism, not a merge into burnInSubtitleIndex - new Party.textSubtitleIndex, new setTextSubtitle/textSubtitleChanged socket pair, mirroring setBurnInSubtitle/burnInChanged's host-only, request/broadcast/react shape exactly. Kept separate from burn-in (rather than reusing one field for both) to avoid touching the already-proven burn-in path - only one subtitle can show at once, so the two are mutually exclusive, enforced server-side in both directions: a real pick on either clears the other. Clearing one to null/"Aucun" is deliberately not treated as a pick for this purpose, so it doesn't clobber an unrelated choice in the other field. Mechanically the two still work nothing alike: burn-in changes the actual encoded stream (ffmpeg), so it reloads for everyone; a text pick only swaps which native <track> each member already renders locally - no reload, no transcode, unless it's the one clearing an active burn-in, which does still need the reload since the stream itself changes back to the normal shared one. Player.ts's subtitle <select> gating stopped being conditional on burn-in - it's simply host-gated now, matching audio/quality, and its value restores from whichever kind of pick (if any) the party currently has. Second, unrelated bug in the same report: audioSelect.value = streamAudioIndex || '' assigned an empty string whenever no audio track had been picked yet (the common default) - since a real audio-track <option> never has value="", this matched nothing and left the select at selectedIndex=-1, a genuinely empty-looking choice. Fixed at both call sites (loadTrackOptions, onStreamOptionsChanged) by only assigning .value when truthy. Server: SocketGateway tests cover setTextSubtitle's host-only gating, broadcast, music no-op, and mutual exclusivity in both directions; PartyService tests cover textSubtitleIndex through create/ advanceQueue/toPublicState. Full typecheck/test/build green on both projects (91/91 server tests). Real-browser check (mocked-fetch + real bundle) confirmed: a follower's subtitle select renders disabled regardless of burn-in state; a host's select restores the party's current text or burn-in pick on load; and the audio select now lands on a real first option instead of an empty one. Not addressed here (raised in the same report, need more diagnostic detail first): occasional sync losses between clients, and a suspicion that per-user watch-status (Emby PlaystateService sync) might be broken. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-14 20:41:02 +02:00
Nicolas	f78b2f1408	One shared Emby stream per party, not one per viewer ... Asked for directly: exactly one stream should ever be open between this app and Emby per party, no matter how many members it has. Before this, every viewer's own <video>/<audio> independently negotiated its own PlaybackInfo and got its own PlaySessionId - a party of 5 meant Emby transcoding the same title 5 separate times. A bigger, higher-regression-risk change than most of this session's other work: it replaces the core playback path every existing party already relies on (CatalogService.proxyStream and its route are gone entirely) rather than adding something alongside it - there's no other consumer of the per-viewer path, and the ask was explicit that there should only ever be one mechanism. - server/src/services/CatalogService.ts: proxyStream's negotiate-then- build-a-target logic extracted into negotiateStreamTarget(session, itemId, isAudio, audioStreamIndex, maxStreamingBitrate) - identical logic, returns the target instead of proxying it directly so it can be cached. proxyStream/proxyRawStreamAsset removed. - server/src/services/PartyStreamService.ts (new): one negotiated target per party.id, reused by every member; renegotiates when the desired item/audio/quality changes. Recovers from a dead upstream session with no new plumbing - EmbyClient.proxyResponse already sets res.statusCode before writing the body, so a failed proxied response is detected right after it resolves and the cache entry is dropped, so the next request (a manual retry, or the next segment fetch) renegotiates fresh instead of repeating the same dead target forever. - server/src/emby/EmbyClient.ts: rewritePlaylist/proxyResponse's trailing itemId param genericized to routeKey - it's only ever read back to build the raw-asset URL, so it's party.id for the new stream routes and an inert real itemId for proxyImage/proxySubtitle (which never reach that branch anyway). - server/src/index.ts: GET /api/catalog/party-stream/:partyId/ master.m3u8 and .../raw replace /api/catalog/stream/:itemId/... entirely, membership-checked like the burn-in routes; a new idle-reap interval for PartyStreamService, same shape as TranscodeService's own. - Forced consequence of "one stream", not a free design choice: audio track/quality become a host-only, party-wide choice for video - Party.streamAudioIndex/streamQuality, setStreamOptions/ streamOptionsChanged, byte-for-byte the same shape setBurnInSubtitle/burnInChanged already established for burn-in subtitles. server/src/realtime/SocketGateway.ts gains the host-only, video-only handler; server/src/services/PartyService.ts resets streamAudioIndex (not streamQuality - a bandwidth preference isn't item-specific) on advanceQueue, same reasoning as burnIn* already gets; MusicQueueService.playNext ends the party's cached session on a track change. - client/src/api/embyApi.ts: streamUrl/audioStreamUrl replaced by one partyStreamUrl(partyId) - no query params needed any more, the party itself is the source of truth for what it's streaming. - client/src/api/party.ts: setStreamOptions/onStreamOptionsChanged. - client/src/views/player/Player.ts: audio/quality <select>s disabled for a follower (applyStreamOptionsGating, mirroring renderSubtitleOptions' own gating), restore the party's current choice on load/broadcast, and a host's change calls setStreamOptions instead of reloading locally - every member (host included) only ever reacts to the resulting broadcast, same discipline the rest of this player already uses. Dead reloadWithCurrentOptions removed. - client/src/musicBar/MusicBar.ts: loadTrack points at partyStreamUrl(activePartyId) - no picker to gate, MusicBar never had one. - server/test/catalogService.test.ts: proxyStream's old cases moved to exercise negotiateStreamTarget instead, plus new quality-override and no-source-fails cases. server/test/partyStreamService.test.ts (new): cache hit/miss/param-change/item-change, the failure-invalidation path, endSession, idle reap. server/test/socketGateway.test.ts: setStreamOptions host-only gating + broadcast, mirroring the existing setBurnInSubtitle tests. - docs/architecture.md, README.md: design, the forced audio/quality trade-off spelled out, and what's still unverified (a different kind than this session's other Emby-API guesses - the calls themselves were already live code, what's untested is real multi-viewer load). Verified: full typecheck+test+build on both projects (85/85 server tests, 12 new). A real-browser check (mocked-fetch + real bundle, this session's standing harness) confirmed a follower's audio/quality selects render disabled and a host's render enabled, from the same party data with only youAreHost flipped. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-14 20:05:34 +02:00
Nicolas	26da8fc5dc	Self-hosted ffmpeg pipeline for PGS (image) subtitle burn-in ... Asked for directly, right after the client-side <track> redesign closed every *text* subtitle case: PGS/VobSub/DVB subtitles (Blu-ray/DVD rips) are bitmaps, not text - there's nothing for Emby's Stream.vtt conversion to extract, so a native <track> fundamentally can't render one. Rather than keep asking Emby's own transcode to burn these in (the exact thing that kept failing in earlier sessions - missing fontconfig, then an unrelated "Error starting ffmpeg"), this runs ffmpeg ourselves: a PGS stream decodes like a second video track, and ffmpeg's `overlay` filter composites it directly - no text rendering, no libass, no fontconfig anywhere in this path. One shared stream per PARTY, not per viewer - explicitly asked for after the initial plan: every member plugs into the exact same server-emitted stream, mirroring "host drives, everyone follows" rather than a per-viewer model. Picking a burn-in subtitle is therefore a host-only, party-wide choice, like play/pause/next already are. - server/src/services/TranscodeService.ts (new): one ffmpeg session per partyId. getOrStartSession negotiates PlaybackInfo (via the new CatalogService.getMediaSource), converts Emby's absolute MediaStreams[].Index into ffmpeg's type-relative 0:s:N/0🅰️N (absoluteToRelativeIndex - pure, unit-tested), and spawns ffmpeg against Emby's own direct/static file endpoint (TODO(verify) - no Emby server reachable from this dev environment, see the function's own comment). Output is real progressive HLS to a temp dir, served by two new routes that poll briefly for the next file. endSession/ reapIdleSessions handle teardown; PartyService's destroy path and advanceQueue both end a party's session immediately, the idle sweep is the backstop. - server/src/services/PartyService.ts: Party/PartyPublicState gain burnInSubtitleIndex/burnInAudioIndex (null together = no burn-in); advanceQueue clears them (a new item's indices mean nothing on the old one). - server/src/realtime/SocketGateway.ts: new host-only "setBurnInSubtitle" handler broadcasting "burnInChanged" - same shape as "next"/ "itemChanged". - server/src/services/CatalogService.ts: new getMediaSource() (id/ container/streams together - what TranscodeService needs); extended the local PlaybackInfoResponse type with Container. - server/src/Logger.ts: new Logger.transcode(). - server/src/index.ts: GET /api/catalog/burn/:partyId/master.m3u8 and .../:segment (membership-checked, same pattern as the party REST routes); a dedicated idle-reap interval for TranscodeService. - server/Dockerfile: `apk add ffmpeg` in the runtime stage - no font packages needed, unlike Emby's own text-subtitle burn-in. - client/src/api/party.ts, client/src/api/embyApi.ts: setBurnInSubtitle/ onBurnInChanged on PartyConnection, burnInStreamUrl(). - client/src/views/player/Player.{html,css,ts}: the subtitle picker's image-track options go from unconditionally disabled to host-only selectable, labeled to say picking one restarts the stream for everyone. Every member (host included) only ever reacts to the resulting "burnInChanged" broadcast - never applies a pick optimistically, same discipline the rest of the player already uses. Audio/quality are disabled while a burn-in is active (one fixed encode); a follower's subtitle select is disabled too (nothing left for them to meaningfully pick). - server/test/transcodeService.test.ts (new): absoluteToRelativeIndex, session start/reuse/replace, endSession, reapIdleSessions - child_process.spawn mocked via a small explicit test seam (setSpawnForTesting), never invoking a real ffmpeg binary. - server/test/socketGateway.test.ts, partyService.test.ts, catalogService.test.ts: host-only gating + broadcast for setBurnInSubtitle, advanceQueue's reset, toPublicState exposing the new fields, getMediaSource. - docs/architecture.md, README.md: design + an explicit "assumptions to verify" note (the direct-source URL shape, first and foremost). Verified: full typecheck+test+build on both projects (56/56 server tests). No Emby server or ffmpeg binary is reachable from this dev environment, so the actual command against a real PGS file is unverified - flagged explicitly in the docs, same "TODO(verify)" spirit already used elsewhere in this codebase for an Emby response shape that can't be checked locally. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-14 18:05:08 +02:00
Nicolas	daab755ce9	Device detection: confirm before disconnecting another device ... Asked for directly: "same account, same device already in the party" should never need a confirmation, "same account, a genuinely different device" should ask before disconnecting it instead of silently overwriting. There was no concept of "device" at all before this - party.members is keyed by userId only. - client/src/deviceId.ts (new): a UUID kept in localStorage (not sessionStorage) - that's what makes "device" mean "browser", not "tab". Falls back to an in-memory id if storage is unavailable. - server/src/types.ts, client/src/api/party.ts: "join" now carries {partyId, deviceId, force?} instead of just {partyId}; new PartyMember.deviceId and "deviceConflict" server->client event (sent only to the joining socket, never broadcast). - server/src/realtime/SocketGateway.ts: the "join" handler now tells three cases apart - no existing connection or the same deviceId reconnecting (attach silently, booting any stale connection for that same device first), a different deviceId with no force (emit deviceConflict and stop - the socket stays connected but inert), or force:true (the confirmed takeover - boot the old connection, take the slot). - server/src/services/PartyService.ts: join() is now idempotent - returns the existing member instead of always building a fresh one. This was itself a real bug independent of the guard below: the REST "Rejoindre" route calls this every time regardless of membership, so a re-click/reload/retry used to silently reset connection/isPaused/ deviceId. - server/src/realtime/SocketGateway.ts: "leave"/"disconnect" now also check party.members.get(userId)?.connection === socket before acting - generalizes the earlier stale-connection crash fix to the new reality where a member can have more than one connection attempt in flight (the superseded one's own eventual "disconnect" must not be read as a real leave). - client/src/views/player/Player.ts, client/src/musicBar/MusicBar.ts: onDeviceConflict wired to a plain confirm() - yes calls the new PartyConnection.confirmDeviceTakeover() (re-sends "join" with force:true), no backs out (navigate home for video, leaveMusicParty for music). - Deliberately does NOT change the home page's live party list itself (still just "Rejoindre" either way) - LobbyPartyDto is one snapshot shared by the whole "lobby" room with no per-viewer membership info, and giving it that is a real protocol change on its own. For video the conflict check above already is the meaningful moment (you can't be looking at the home page from inside your own party on the same tab - the player is a full-screen takeover), so this doesn't cost the feature much: Rejoindre reaches the check immediately, same device reconnects silently, a different device asks first. See docs/architecture.md for the fuller reasoning. - server/test/socketGateway.test.ts, server/test/partyService.test.ts: new tests for the conflict/takeover/reconnect paths and join()'s idempotency; the earlier stale-connection crash regression test updated to reach the same shared-slot shape through a real device takeover instead of a raw PartyService.join() call (which no longer reproduces it now that join() is idempotent). Verified: full typecheck+test+build on both projects (39/39 server tests passing); confirmed the "leave"/"disconnect" guard is load- bearing by temporarily reverting it and watching the new takeover test fail, then restoring it; deviceId.ts's localStorage persistence checked against the real compiled bundle in a real browser (survives a reload, stable across calls). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-14 17:32:21 +02:00
Nicolas	c14d0bc08b	Replace avatar-click with a request toolbar; add "request resume" ... Asked for directly: a visible bottom toolbar for non-host members instead of clicking your own small avatar circle (never a very discoverable affordance), and a second request alongside pause - "please resume". - server/src/types.ts, server/src/realtime/SocketGateway.ts: new requestResume/resumeRequested, byte-for-byte the same shape and handler pattern as requestPause/pauseRequested, independently throttled (its own lastResumeRequestUtc - not a shared budget with pause). Kept as a plain broadcast signal, same as pause always was - no accept/deny state tracked server-side, the host sees the same banner/avatar highlight as everyone else and acts with their own existing controls. - client/src/api/party.ts, client/src/types.ts: requestResume() on PartyConnection, onResumeRequested callback, a ResumeRequestedMsg type (same shape as PauseRequestedMsg, kept separate so a callback's own signature says which request it's for). - client/src/views/player/Player.{html,css,ts}: the avatar is presence- only now (no click handler, no "- demander une pause" title) - a new .bottomOverlay wraps the request banner, the follower notice, and a new .requestToolbar (Demander une pause / Demander une reprise) as one flex column, same "stack in normal flow instead of hand-picking a pixel offset per box" fix .topOverlay already needed. Pause and resume share one showRequestBanner() - they only ever differed by which word appears in the banner text. Renamed the shared CSS classes (avatarPauseRequested/avatarPauseBadge -> avatarActionRequested/ avatarRequestBadge) since they're no longer pause-specific. - server/test/socketGateway.test.ts: new case confirming requestResume's throttle is independent from requestPause's own. Verified against the real compiled bundle: the toolbar shows for a follower and stays hidden for the host; each button's own client-side cooldown collapses a rapid double-click to one emission; a pushed resumeRequested shows the banner with the right text and highlights the right avatar. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-14 17:09:01 +02:00
Nicolas	b2310216ce	Fix settings menu visibility bug; make the music player a persistent bar ... Fix: player settings menu stuck permanently open ---------------------------------------------- .hide { display: none; } and Player.css's .settingsPanel { display: flex; ... } are both single-class selectors - equal specificity - so whichever one esbuild happened to bundle later into app.css won the `display` property on an element carrying both classes. Player.css's own display:flex always landed after base.css's .hide, so #settingsPanel showed regardless of the hide class ever being toggled - the toggle logic itself was correct the whole time, it just had no visible effect. Fixed at the utility class, not the one call site: `.hide` now uses `display: none !important`, which wins a same-specificity tie regardless of bundling order - closes off the whole bug class, since several other components already set their own `display` for a visible state. Feature: music player is now a persistent bottom bar, not a page ------------------------------------------------------------------ The music player was its own route (/party/:id -> views/musicPlayer/), which meant navigating anywhere else - the sidebar, an album to queue up more tracks - tore the whole thing down (router.ts calls a route's cleanup, which used to call leaveParty, on every hash change). No way to browse and listen at the same time. - client/src/musicBar/MusicBar.ts (new): a Shell-level singleton, mounted once into a #musicBar element that's a sibling of #mainContent, never touched by route changes. Renders as a fixed bottom bar. Exposes initMusicBar/joinMusicParty/leaveMusicParty instead of the router's render()-returns-cleanup pattern, since it never registers as a route. - views/player/Player.ts's dispatcher: a music party no longer renders a page - it calls joinMusicParty() and bounces back to /home (a no-op for every reachable call site except album's). A video party now calls leaveMusicParty() first (harmless no-op if nothing's active) - starting or joining a video watch party always leaves the listen party, since every party-join call site already funnels through this one dispatcher. - views/album/Album.ts: the last per-track "start a party" UI now that the music player's own inline browse panel is gone (browsing just means navigating there normally). Each track's button starts a new party or adds to whichever one is already active, decided by getActiveMusicPartyId() at CLICK time (not render time) so the action taken is always correct even if the label is momentarily stale; every button is relabeled in place after a successful click. Starting a party from here no longer navigates away at all. - views/musicPlayer/ deleted entirely (MusicPlayer.ts/.html/.css) - superseded by musicBar/. - Comment updates in global.d.ts/presence.css/trackList.css/party.ts/ types.ts that named the old module by path. Verified both fixes by rebuilding and driving the real compiled bundle through a local static server, with fetch/window.io/window.Hls mocked: starting a party from an album track leaves the sidebar/page in place and relabels the other tracks; adding a track posts to the already-active party's id; navigating into a video party hides the bar, disconnects its socket, and posts a real leave for the music party before the video player renders; the settings gear opens/closes correctly for the host in that same run. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-14 10:43:12 +02:00
Nicolas	4a31ee741e	Rewrite server + client in TypeScript, service-oriented server architecture ... Full rewrite, requested directly. Two independent decisions since TypeScript can't compile itself away at runtime - "no build step" and "TypeScript" are mutually exclusive, not a small addition to the existing setup: - Server: plain tsc (no bundling need - Node resolves its own requires). server/dist mirrors server/src 1:1. - Client: esbuild (does need bundling) - picked over a heavier tool (Vite, webpack) since this app's whole client is a couple thousand lines; its built-in CSS-from-JS bundling and a `text` loader for importing an HTML template as a string cover everything needed via a ~30-line hand-written build script (client/build.mjs), not a config file for something built for much bigger apps. Both projects compile independently (no shared-types package - considered and rejected as more structural commitment than this app's size justifies; server/src/types.ts and client/src/types.ts have their own overlapping DTO copies instead). server/'s `npm run dev` uses tsx for a compile-free dev loop; `npm run build` (tsc) is what server/Dockerfile's build stage actually runs. client/'s `npm run watch` is esbuild's own watch mode. Server: one singleton service class per feature, generalizing the PartyManager/MusicQueueService pattern that already existed, rather than route handlers with logic inline: - AuthService (from embyAuth.js), CatalogService (NEW - previously ~15 route handlers' worth of Emby queries/DTO shaping inlined directly in index.js), PartyService (renamed from PartyManager), MusicQueueService (ported as-is, already service-shaped), SocketGateway (from socketHandler.js), EmbyClient (from embyProxy.js - low-level plumbing, not called a "service" since it has no state/feature of its own). - index.ts is now thin wiring only: every route reads the session, calls one service method, returns the result. - Real error-handling pass, not just a port: Express 4 doesn't catch a rejected Promise from an async handler on its own - a new asyncRoute() wrapper + a single error-handling middleware replace what used to be zero handling for a request that outright throws. CatalogService methods throw a CatalogFetchError (own HTTP status - getRawItem now preserves Emby's real 404 instead of a blanket 502) rather than touching res directly. Client: one folder per view (src/views/<name>/<Name>.ts + .html + .css) instead of one .js file with the markup inline as a template literal. A view's static shell moved to its .html (esbuild's text loader); per-item dynamic content (tile grids, episode/track lists) stays as template -literal-returning functions in the .ts, same as before. Genuinely shared CSS (tiles, the presence avatar, the series/album detail-header pattern, track-list rows) lives under src/styles/, imported by whichever views need it; src/styles/base.css holds the global primitives, imported once by app.ts. Deliberately not pushed to zero duplication/renaming shared classes across views for tidiness alone - not worth the risk in a change already this large. Player.ts keeps its pre-existing internal shape (the /party/:id dispatcher + the video renderer in one file, importing renderMusicPlayer from the sibling folder) - that pattern predates this rewrite and only needed types, not restructuring. Two real things the port itself caught, not just carried over: - A type bug: porting SocketGateway's "members" broadcast, reusing PartyService's PublicMember interface would have type-checked fine but was the wrong (larger) shape - the socket broadcast never included isPaused/positionTicks, only the REST response did. Caught by comparing against the original JS line by line, fixed with a dedicated SocketMemberDto type. - A real Express+TypeScript friction point: noUncheckedIndexedAccess (enabled in both tsconfigs - genuinely useful elsewhere, e.g. PartyService.advanceQueue's array indexing) makes every req.params.xxx read a type error, since Express's index-signature typing doesn't know a matched route's required :name segment is always present. Resolved once with a param(req, name) helper rather than 15 routes' worth of scattered assertions. Verified: both projects type-check cleanly in strict mode (tsc --noEmit - not just "esbuild didn't complain", which it wouldn't even with type errors present, since it transpiles without checking). Server: every unit/integration test from the JS version (party lifecycle logging, the music queue's timer/vote/pause behavior incl. real setTimeout auto-advance, the socket integration through SocketGateway+PartyService+ MusicQueueService together, the library-type filter, the playback -override forcing) re-run against the compiled server/dist output - identical results; the compiled server was actually started and confirmed listening cleanly. Client: since esbuild bundles everything into one app.js (no more individually-importable view modules), testing moved to driving the real compiled bundle through its actual boot -> login -> router -> view chain (mocked fetch/Socket.IO/hls.js, real clicks/hash navigation) - arguably more realistic than the old per-module approach. Confirmed this way: login, the sidebar, home's carousels, a video party (presence, host controls, leave), the full music hierarchy, a music party (presence, vote-skip, pause toggle, the inline browse-and-add panel), and the series page - all through client/dist's actual output, no thrown errors anywhere. Not verified: an actual `docker build` of the new multi-stage Dockerfile - this dev environment has no Docker at all. The build stage runs the exact npm run build commands already confirmed working locally, just inside node:20-alpine - the main remaining risk is something environment -specific, not the build commands themselves, but a real build is still the first thing to try after this lands. docs/architecture.md has the full writeup (new "TypeScript and a service-oriented architecture" section, plus a corrected top-level "Components" overview that had gone stale even before this change). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-14 09:38:14 +02:00