sindresorhus/electron-store

This didn't work out for me for some reason, but for a simple settings/json store in electron it is easy enough to use lowDb, which has a json mode to assure that atomic updates to the file are made, and I'm pairing that with safeStorage to make sure that I can encrypt a key via that, then store it encrypted in the json, and then use that to encrypt the sqlite database. I don't know how good of a solution that is, but it seems like something that could be viable.

Summary

electron-store is a JavaScript module that adds simple JSON-file persistence to Electron applications. It reads and writes a config.json file in Electron's userData directory, giving apps a place to save user preferences, UI state, and small caches without a database. The package is native ESM, requires Electron 30 or later, and is MIT-licensed.

What it is useful for

The module fits the common Electron need of remembering settings between launches — window size, theme, recent files, feature flags, or last-opened project paths. Because the entire JSON file is rewritten on each change, the README explicitly warns it is not a database and slows down with even moderately large payloads (1 MB+). It works well for a few hundred kilobytes of structured config but not for log streams, document bodies, or binary blobs.

It also adds structure the raw filesystem does not: JSON Schema validation via ajv so a bad value throws instead of corrupting state, atomic writes that survive mid-write crashes, dot-notation access for nested keys, change listeners (onDidChange, onDidAnyChange), optional AES-256 encryption (for obfuscation, not security, since the key lives in the same app), and a migrations system for upgrading stored data across app versions.

How engineers can use it

Install with the documented command:

npm install electron-store

Then, in the main process:

import Store from 'electron-store';

const store = new Store();

store.set('unicorn', '🦄');
console.log(store.get('unicorn'));
//=> '🦄'

store.set('foo.bar', true);
console.log(store.get('foo'));
//=> {bar: true}

store.delete('unicorn');

For typed data, pass a schema using JSON Schema (draft 2020-12). Declaring foo as type: 'number' with a default of 50 makes store.set('foo', '1') throw a schema violation. To keep a separate file, use the name option; to change directory, use cwd (the README warns against this unless necessary).

Two documented constraints shape real usage. First, the module is ESM only, so CommonJS projects must convert before importing it. Second, because modern Electron disables Node integration in the renderer by default, importing the module directly in renderer or preload scripts will fail with Can't resolve 'fs'. The recommended pattern is to keep the store in the main process and expose it through ipcMain.handle and ipcRenderer.invoke, or call Store.initRenderer() in the main process when a renderer-only setup is acceptable. The README also flags the migrations option as having known bugs and being unsupported by the author, so teams planning schema evolution should treat that path with caution.