ReferenceError: window is not defined — window.navigator accessed without environment guard (breaks SSR / Node)

[tacres-beep]

Summary

Several internal code paths reference window directly without a typeof window === "undefined" guard. The clearest offender is the internal user-agent helper, whose constructor reads window.navigator.userAgent unconditionally:

  class ... extends ... { constructor() { super(window.navigator.userAgent) } ... }

In any non-browser environment (Node, SSR, server-side prerendering, unit tests under jsdom-less setups), reaching code that instantiates this helper throws:

   ReferenceError: window is not defined

This is awkward for SSR frameworks (Next.js, Remix, etc.), where modules are evaluated and components are rendered on the server. Consumers currently have to work around it by forcing client-only loading (e.g. Next's dynamic(..., { ssr: false })).

Environment

@millicast/sdk: 0.1.43
Node: v20.19.6
Consumer stack (where originally observed): Next.js 14.2.35 (App Router) + React, server-side render of a "use client" component

Minimal reproduction

// repro.mjs — run with: node repro.mjs   (no DOM / no window)
import { PeerConnection } from "@millicast/sdk";
// Throws: ReferenceError: window is not defined
PeerConnection.getCapabilities("video");

Result:

ReferenceError: window is not defined
    at new <UserAgent helper> (.../dist/millicast.esm.js)  // constructor: super(window.navigator.userAgent)
    ...

Expected behaviour

The SDK should not throw merely for being loaded/exercised in a non-browser environment. Browser-only APIs (window, window.navigator, window.atob) should be accessed behind environment guards, falling back gracefully (or throwing a clear, documented "browser-only API" error) when window/navigator are unavailable.