window is not defined: The Next.js SSR Problem

"ReferenceError: window is not defined" — if you've built a Next.js app, you've seen this error. It happens when code that accesses browser-only APIs runs on the server during server-side rendering. AI assistants write this bug constantly because they don't distinguish between client and server contexts.

Why it happens

Next.js renders pages on the server first, then hydrates them on the client. Code that runs at the module level or during initial render executes in Node.js, where window, document, localStorage, and other browser APIs don't exist.

AI assistants generate code like:

const width = window.innerWidth; const theme = localStorage.getItem('theme'); document.addEventListener('click', handler);

All of these crash during SSR.

The fix pattern

The solution is to guard browser API access with a check or move it into a useEffect hook:

const width = typeof window !== 'undefined' ? window.innerWidth : 0;

Or for side effects:

useEffect(() => { document.addEventListener('click', handler); return () => document.removeEventListener('click', handler); }, []);

The challenge is that there are dozens of browser-only APIs, and AI-generated code scatters them throughout components without guards.

What FRONT002 catches

FRONT002 scans JavaScript and TypeScript files for direct access to window, document, navigator, localStorage, sessionStorage, and other browser-only globals outside of useEffect, componentDidMount, or typeof guards. It catches the crash before your users do.

This is especially valuable in codebases where AI generated multiple components that all assume a browser environment.