electron-is-dev

electron-is-dev is a tiny utility for Electron applications that answers one question reliably: is the app currently running in development, or in a packaged production build? It checks the ELECTRON_IS_DEV environment variable first, falling back to Electron’s own app.isPackaged property when that variable isn’t set, so developers can enable debug tooling, verbose logging, or dev-only menu items without hand-rolling that detection logic in every project.

Maintained by Sindre Sorhus, the package predates Electron’s native app.isPackaged API and remains useful today because it lets you override the detected environment on demand via an environment variable — handy for testing production code paths locally or forcing debug behavior in a packaged build. It must be imported from the Electron main process, since it depends on the electron module being available as an object rather than the string placeholder Node.js substitutes outside of Electron.

What You Get

• A single boolean export (isDev) computed once at import time, with no function calls or async setup needed.
• Automatic detection via Electron’s app.isPackaged, so it works correctly out of the box in any main process.
• An ELECTRON_IS_DEV environment variable override for forcing dev or production behavior regardless of packaging state.
• Full TypeScript types (index.d.ts) exporting a plain boolean, verified against the implementation with tsd in CI.

Common Use Cases

• Enabling Chrome DevTools or verbose console logging only when developing locally.
• Loading a webpack-dev-server or Vite dev URL instead of packaged HTML files during development.
• Gating installation of hot-reload or debug-only tooling so it never ships in a production build.
• Forcing production-like behavior during local testing by setting ELECTRON_IS_DEV=0.

Under The Hood

Architecture The entire implementation is a single ES module (index.js) of roughly a dozen lines: it imports Electron, guards against being loaded outside an Electron process (Electron replaces its own module with a string path when required from plain Node.js, so a typeof electron === 'string' check throws a clear TypeError early), then resolves isDev by checking process.env.ELECTRON_IS_DEV before falling back to !electron.app.isPackaged. There are no layers, classes, or internal abstractions to trace — the module computes its exported value once at import time and is done, which is exactly the right shape for a single-purpose environment-detection utility.

Tech Stack The package has zero runtime dependencies and targets Node.js 18+. It’s published as type: module (ESM-only) with a dual entry defined via the exports field pointing to index.js and its companion index.d.ts types. Development tooling is limited to xo (a preconfigured, strict ESLint wrapper) for linting and tsd for type-checking the declaration file against real usage, both run through a single npm test script and GitHub Actions CI across Node 18 and 20.

Code Quality There is no behavioral test suite — index.test-d.ts only exercises tsd’s expectType<boolean>(isDev) to confirm the exported type shape, it does not assert runtime values under different environment conditions. Error handling is limited to a single explicit TypeError thrown when the module is misused outside Electron, which is an appropriate, honest failure mode for a two-branch utility. Code style is enforced by xo’s strict defaults rather than a custom ESLint config, and CI runs on every push and pull request across two Node versions, giving reasonable confidence the tiny surface area still works as expected.

API Design The developer experience is about as low-friction as a package can get: a single default import gives you a ready-to-use boolean, with no configuration, no async initialization, and no methods to learn. The one piece of hidden API surface — the ELECTRON_IS_DEV environment variable override — is documented directly in the README rather than buried in code, and the FAQ section proactively answers the two questions a developer is most likely to have (how this differs from app.isPackaged, and how to use the value in the renderer process via contextBridge).