Electron Fiddle: a scratchpad for Electron experiments, now a Yarn monorepo heading into a 1.0 alpha

A template, a version picker and two places to save

Electron Fiddle opens on a quick-start template. You edit a few things, pick the Electron version that should run the code, and launch it. When the experiment shows what you wanted, you save it either as a GitHub Gist or to a local folder, and anyone with Fiddle can open it and run the same thing.

That loop is the whole point of the app: a small, reproducible Electron program tied to a specific Electron version. It is the format you want for a bug report against Electron itself, or for checking whether an API behaves differently between two releases. The packaged app is distributed from https://www.electronjs.org/fiddle, and that download is the intended entry point for people who only want to run fiddles.

The cost of the Gist path is that sharing goes through GitHub. If your experiment contains code you cannot publish, the local folder option keeps it on disk, but then the person you send it to needs the folder itself rather than a link.

Two workspaces: the app and a trimmed port of fiddle-core

The repository is a Yarn workspaces monorepo named electron-fiddle-monorepo, with every package under packages/. There are two.

electron-fiddle lives in packages/app. It is the Electron app proper: main process, preload script, renderer, and the packaging setup in forge.config.ts.

@electron/fiddle-core lives in packages/core. It is the part that downloads Electron versions and spawns fiddles. It is described as a trimmed port of the separate electron/fiddle-core project, not that project itself.

That word trimmed has a consequence for anyone who already scripts against the standalone fiddle-core library. The copy inside this monorepo carries the same package name but is cut down to what the app needs, so you cannot assume every API from the standalone library exists here. If your tooling depends on fiddle-core, keep depending on the standalone project and treat packages/core as an internal module of the app.

Building from source pins Node to three release lines

Contributors need the Node.js version recorded in .nvmrc. The root package.json backs that up with an engines field of ^22.22.2 || ^24.15.0 || >=26.0.0, so an older patch release of Node 22 or 24 falls outside the allowed range. Yarn itself does not need to be installed separately in a matching version: it is vendored in .yarn/releases, and packageManager is set to [email protected].

The day to day commands are:

yarn             # install dependencies
yarn start       # run the app, with hot reload
yarn test        # unit and component tests
yarn test:e2e    # end-to-end tests against a real build

Packaging is done with yarn package or yarn make, and both put their output in packages/app/out/. There is no published npm install route for the app; if you are not contributing, the download page is the way in, and a source build is extra work you do not need.

Every test, lint and typecheck run regenerates bindings first

Several root scripts start with yarn generate. typecheck runs yarn generate and then tsc -b. lint and lint:fix run yarn generate before eslint --cache. test runs yarn generate before vitest run, and test:e2e does the same before running Vitest with packages/app/e2e/vitest.config.mts.

yarn generate regenerates bindings and catalogs that are committed to the repository. Two things follow from that. First, each of these commands pays the generation cost before doing its real work, so even a quick lint is not just a lint. Second, because the generated files are committed, running a check can leave modified files in your working tree. If you see a diff you did not write after running tests, check whether it came from generation before you commit it.

test:watch is the exception: it runs vitest directly without generating, so it can go stale if you change the inputs that generation reads.

The 1.0 line is an alpha resting on alpha Forge packages

The release history is short and recent. v0.38.0 was tagged on 2026-02-05, v0.39.0 on 2026-04-08, and v1.0.0-alpha.0 on 2026-10-30. The latest push to main was on 2026-11-01, so the project is under active development.

The 1.0 tag is explicitly an alpha. The root package.json also pins @electron-forge/maker-base and @electron-forge/shared-types to 8.0.0-alpha.10 through resolutions, which means packaging depends on a prerelease of Electron Forge as well. Other resolutions pin dompurify to 3.4.17 and apply a local patch to electron-windows-msix 2.0.4.

For a user, this means the newest build is two layers of prerelease deep: an alpha app on an alpha packaging toolchain. If you need a version that behaves the same next month, v0.39.0 is the most recent tag without an alpha suffix. If you are packaging a fork, expect the Forge alpha and the msix patch to be the first things that break when you bump dependencies.

Headless runs and a driver script for automation

Beyond the interactive app, the root package.json exposes entry points meant for scripts rather than people. fiddle runs node packages/app/tools/electron-run.mjs headless. driver runs packages/app/tools/driver.ts through node with ExperimentalWarning and MODULE_TYPELESS_PACKAGE_JSON warnings disabled. start:xvfb starts the app workspace under an xvfb variant of its start script, which is the route for running it on a machine without a display.

These are development tools inside the repository, not a public command line interface. They are not described as a stable surface, and their names point to files under packages/app/tools, so they can move whenever the app is restructured. If you want to automate fiddle runs in CI, building on these scripts ties you to the monorepo layout and to a source checkout with the correct Node version.

Localization scripts and a design system live in the same tree

The app is translated, and the tooling for that sits at the root: i18n:check, i18n:translate and i18n:test all forward to the electron-fiddle workspace, and eslint-plugin-i18next is among the dev dependencies, so lint rules cover translatable strings.

The docs/design/ folder holds the reference for Lucent, the design system the app uses, with a handover page and the tokens. That folder is design reference, not user documentation for writing fiddles. Anyone looking for a guide to Electron APIs or to the fiddle file format will not find it there; that material belongs to Electron's own documentation.

The repository also carries a CLAUDE.md file and a .claude/ directory at the top level alongside CONTRIBUTING.md. Contributions are routed through CONTRIBUTING.md, security reports through SECURITY.md, and the code is MIT licensed. Use of the Electron or GitHub logos falls under GitHub's logo guidelines.

Editorial conclusion

Use Electron Fiddle if you need to reproduce an Electron behavior on a specific Electron version and hand someone a Gist or folder they can run; download the packaged app rather than building it. Build from source only if you plan to contribute, and match the Node version in .nvmrc first. Before relying on the 1.0 line, check whether v1.0.0-alpha.0 has been followed by a stable release, because it is an alpha resting on alpha Electron Forge packages; v0.39.0 is the latest non-alpha tag.

Frequently asked questions

Official sources

1. electron/fiddle on GitHub
2. License: MIT
3. Project website
4. README
5. Releases