isDevtoolsActive

isDevtoolsActive(): boolean

Defined in: packages/three-flatland/src/debug-protocol.ts:229

Layer 1 (build-time): the devtools build gate. Every devtools call site is guarded by one consistent, hard-coded expression written directly at the gate — never a named const, never an import:

if (process.env.NODE_ENV !== 'production' || process.env.FL_DEVTOOLS === 'true') {
  // devtools-only work
}

Two switches:

• process.env.NODE_ENV !== 'production' — every bundler (webpack, Vite, esbuild, Rollup) and Node statically replaces NODE_ENV, so a production build folds this to false.
• process.env.FL_DEVTOOLS === 'true' — the repo’s own escape hatch: a production-mode build that defines process.env.FL_DEVTOOLS = 'true' (the examples do) keeps devtools; everything else folds it away.

The expression is inlined per gate site — never hoisted into a named const, never imported from a shared exported const. A local or cross-module const is NOT inlined by every bundler (esbuild in particular keeps it as a live binding), which defeats the dead-strip and ships the whole devtools subsystem. Writing the literal process.env.* reads at each gate lets every bundler replace-then-dead-strip locally. The negated form (for early-return guards) is the De Morgan inverse: process.env.NODE_ENV === 'production' && process.env.FL_DEVTOOLS !== 'true'.

Layer 2 (runtime): isDevtoolsActive(). Only reachable when the gate is true. Reads window.__FLATLAND_DEVTOOLS__ as an opt-out (false disables an otherwise-bundled build). Cannot enable what isn’t bundled — rogue clients can’t “hack devtools on” in prod.

Build state	window.__FLATLAND_DEVTOOLS__	Enabled?
dev (NODE_ENV !== 'production') or FL_DEVTOOLS='true'	undefined	yes (default on)
dev or FL_DEVTOOLS='true'	false	no (user disabled)
dev or FL_DEVTOOLS='true'	true	yes (explicit)
production, no opt-in	anything	no (code not in bundle)

Returns

boolean