fix(front): keep unset LIVEKIT_WS/LOVE_ENDPOINT undefined in /config.json

[clayrisser]

Problem

pods/front/src/__start.ts:35-36 coerces two unset LiveKit variables to the empty string:

LIVEKIT_WS: process.env.LIVEKIT_WS ?? '',
LOVE_ENDPOINT: process.env.LOVE_ENDPOINT ?? '',

But the love client tests for undefined, not for falsy (plugins/love-resources/src/components/Room.svelte:42):

if (wsURL === undefined) {

So on a deployment that does not configure LiveKit, wsURL is '' rather than undefined, the guard does not fire, and Office reports itself as configured. It then fails at connect time instead of hiding the feature — an error where there should have been an absence.

CALDAV_SERVER_URL on line 52 of the same object already does the right thing:

CALDAV_SERVER_URL: process.env.CALDAV_SERVER_URL,

Undefined keys are omitted from the served config JSON, which is what the undefined check on the client side is written against.

Fix

Drop the two ?? '' coercions, matching CALDAV_SERVER_URL:

-  LIVEKIT_WS: process.env.LIVEKIT_WS ?? '',
-  LOVE_ENDPOINT: process.env.LOVE_ENDPOINT ?? '',
+  LIVEKIT_WS: process.env.LIVEKIT_WS,
+  LOVE_ENDPOINT: process.env.LOVE_ENDPOINT,

Scope and residual risk

• A deployment that sets both variables sees no change — the coercion only ever mattered when the variable was unset.
• A deployment that sets them to the empty string explicitly moves from "empty string" to "empty string"; unchanged.
• The only behaviour that changes is the unset case, which is currently broken.
• If any consumer elsewhere reads LIVEKIT_WS expecting a string rather than string | undefined, this would surface it. I checked the love client path, which is the gate that motivated this; I have not exhaustively audited every reader, so a second pair of eyes on that is welcome.

Verification

Verified against develop @ 1be6047c8: the two ?? '' coercions are still at __start.ts:35-36, CALDAV_SERVER_URL at :52 still has none, and Room.svelte:42 still gates on wsURL === undefined. git apply is clean.

Manual check: with LIVEKIT_WS and LOVE_ENDPOINT unset, /config.json should omit both keys, and Office should hide rather than appear available and fail on connect.

Provenance

Found on a self-hosted deployment that runs without LiveKit: Office appeared available to users and failed when they clicked into it.

[clayrisser]

Closing — this was opened by an automated agent without my intent. Apologies for the noise.