electron-devtools-installer

electron-devtools-installer automates a chore every Electron developer runs into: getting Chrome DevTools extensions like Redux DevTools, React Developer Tools, or Vue.js Devtools working inside an Electron app’s debugging session. Instead of manually downloading a CRX file, extracting it, and wiring up the extension path by hand for every machine on a team, the package fetches the extension straight from the Chrome Web Store, caches it under the app’s userData directory, and loads it into an Electron session with a single function call.

The API is a single installExtension() call from the main process, accepting either a bare Chrome Web Store extension ID or one of the package’s built-in constants (REDUX_DEVTOOLS, REACT_DEVELOPER_TOOLS, VUEJS_DEVTOOLS, EMBER_INSPECTOR, and others), singular or as an array for installing several extensions in sequence. It skips re-downloading extensions that are already loaded unless forceDownload is set, supports installing into a specific Electron Session rather than only the default one, and can enable file:// URL access for apps that load local files. It has shipped since 2016 and remains widely used across the Electron ecosystem as the de facto way to bootstrap devtools during development.

What You Get

• A single installExtension() function that downloads, caches, and loads a Chrome Web Store extension into an Electron session
• Built-in ExtensionReference constants for popular devtools (Redux, React, Vue.js, Ember, Backbone, jQuery, MobX, Apollo) so you don’t have to look up Chrome Web Store IDs yourself
• Automatic skip-if-already-installed behavior, with an optional forceDownload flag to force a fresh fetch and reload
• Support for installing into any Electron Session object, not just session.defaultSession, for apps that manage multiple sessions
• loadExtensionOptions passthrough (e.g. allowFileAccess) so devtools also work against pages loaded via file://
• Retry-with-backoff downloading of the extension’s .crx package directly from the Chrome Web Store, with automatic extraction and permission fixup

Common Use Cases

• Wiring Redux DevTools into an Electron app’s main process during local development
• Installing React Developer Tools or Vue.js Devtools to inspect component trees inside an Electron-rendered UI
• Bootstrapping a consistent devtools setup across a team without everyone manually downloading and pathing extensions
• Enabling devtools extensions for apps that load their renderer via file:// instead of http(s)://
• Reinstalling a fresh copy of an extension after a Chrome Web Store update, via forceDownload

Under The Hood

Architecture The package is a small, single-purpose module split across three files: src/index.ts (the public API surface — the installExtension function, the ExtensionReference type, and pre-defined extension-ID constants like REDUX_DEVTOOLS and REACT_DEVELOPER_TOOLS), src/downloadChromeExtension.ts (a recursive, retry-based downloader that fetches, unzips, and caches a .crx from the Chrome Web Store), and src/utils.ts (low-level Electron net/Node https download and filesystem-permission helpers). Control flow is linear: installExtension resolves the target Electron session, checks extensions already loaded via the session’s getAllExtensions(), and — unless the extension is already present and forceDownload isn’t set — delegates to downloadChromeExtension to fetch and cache the .crx under app.getPath('userData')/extensions/<id> before calling session.loadExtension(). Array input is handled with a reduce-based promise chain rather than Promise.all, guaranteeing extensions install in a defined sequence. There’s no dependency injection, plugin system, or internal layering — it’s a flat utility module, so the entire public surface is effectively one function; changing its signature would break every consumer directly.

Tech Stack Written in TypeScript (strict mode, compiled via tsc to CommonJS targeting es2017) with a single runtime dependency, unzip-crx-3, for extracting the downloaded extension package. Downloads go through Electron’s own net.request (falling back to Node’s https.get for pre-1.4.5 Electron), and filesystem work uses plain Node fs/path — no bundler and no framework. The test/CI stack uses electron-mocha (so specs run inside a real Electron process), chai/chai-as-promised/chai-fs for assertions, ts-node for on-the-fly TypeScript execution, prettier for formatting, and semantic-release driven by CircleCI for automated versioning and npm publishing. The package ships as compiled JS plus .d.ts declarations, with only LICENSE, README.md, and dist/ published.

Code Quality Tests live in test/install_spec.ts and test/download_spec.ts, run through electron-mocha with chai/chai-as-promised/chai-fs assertions and mocha-testdata for data-driven cases; test/setup.ts wires up the promise-assertion plugin. TypeScript strict mode is enabled across src/, and ESLint (airbnb-base) plus Prettier enforce consistent formatting; CircleCI runs the full prettier:check + test suite on every push, and semantic-release automates version bumps from commit messages. Error handling is explicit rather than swallowed — downloadChromeExtension retries with backoff and surfaces the underlying error after exhausting attempts, and installExtension rejects explicitly if called outside the main process. Test coverage is limited to two spec files, reflecting the package’s narrow surface area rather than a gap in rigor.

API Design The public API is deliberately tiny: one function, installExtension, that accepts a bare Chrome Web Store ID string or an {id} object, singular or as an array, plus a small options bag (forceDownload, session, loadExtensionOptions). Shipping ready-made ExtensionReference constants for the most commonly used devtools extensions means most consumers never look up an extension ID themselves, and the automatic already-installed check means calling installExtension repeatedly is safe and idempotent by default. The README documents the common cases — single extension, multiple extensions, and file:// access — with runnable snippets, so getting started requires copying a few lines into an app’s main process with no additional configuration.