electron/minimal-repro: the four-file Electron app built for bug reports

What electron/minimal-repro is actually for

The README opens with the purpose in one line: "Quickly create and share examples of Electron app behaviors or bugs." That is the whole product. The repository was renamed from electron-quick-start, and the README now carries a note telling anyone who wants to start a real application to look at Electron Forge instead. Read that as a deliberate narrowing of scope rather than a deprecation.

The audience is narrow too. It is for the person who has hit something odd in an Electron app and needs a second party to see it: a maintainer triaging an issue, a contributor preparing a pull request, or two engineers disagreeing about whether a bug lives in their code or in Electron itself. A reproduction that runs in four files removes the argument about environment setup, because there is nothing in it to configure.

The repository has not been archived and the last push was on 2026-10-28, so the template is still being touched. That says nothing about how quickly issues get answered, and the README does not promise any support channel.

The four files and how a window gets on screen

The README lists four components and the repository root confirms them: package.json, main.js, index.html and preload.js, with renderer.js and styles.css alongside. The split matters because it mirrors Electron's process model.

main.js is the main process. package.json sets "main": "main.js", so that is the file Electron loads first, and the README describes it as the code that "Starts the app and creates a browser window to render HTML." index.html is the renderer process, the page drawn inside that window. preload.js is described as "a content script that runs before the renderer process loads", which is the layer that sits between the two processes. renderer.js holds page-side logic and styles.css holds presentation, though the README does not call either of them out.

That is the entire data flow. There is no bundler, no build step, no transpiler, no framework and no test harness. The dependency list in package.json contains exactly one entry, electron ^45.0.0, under devDependencies. If a bug needs a bundler or a framework to appear, this template cannot host it without you adding one, and adding one defeats the point.

Install and first run from a clean clone

The README states the prerequisites plainly: Git and Node.js, which brings npm with it. From a command line, the documented sequence is clone, enter the directory, install, run.

git clone https://github.com/electron/minimal-repro
cd minimal-repro
npm install
npm start

npm install pulls the single devDependency, electron ^45.0.0, which is a large download because it fetches a prebuilt Electron binary. npm start resolves to the start script in package.json, which is "electron .", so Electron reads the main field and launches main.js. What you should see is a window showing the page from index.html. The README does not describe the window's title, size or contents, so treat the first launch as a smoke test: if a window opens, the toolchain is working and you can start cutting the app down to the behaviour you want to demonstrate.

The README also notes that Linux Bash for Windows users may need a separate guide for running graphical Linux desktop applications, or may need to invoke node from the command prompt. If no window appears on that setup, the problem is the display environment, not the template.

Where this template stops being the right tool

The README's own note is the clearest limitation: if you are looking to bootstrap a new Electron app, go to the Electron Forge docs. minimal-repro has no packaging, no code signing, no installer generation, no auto-update and no application icon configuration. It has one npm script, start. A project that needs a distributable artifact has to add all of that, and at that point the template has contributed nothing except a window.

There is a second, quieter failure mode. A minimal repro is only minimal if you keep it minimal. The moment you copy a real application's main process setup into it, you have recreated the environment you were trying to escape, and the person reading your issue is back to guessing which of your changes caused the behaviour. The template does not enforce anything. It is four files and a dependency, and discipline is entirely yours.

Version drift is the third constraint. The pinned range is electron ^45.0.0, so npm install may resolve to a newer 45.x than the reporter used. If a behaviour depends on an exact Electron build, the caret range is not enough on its own, and the README says nothing about pinning or about which versions the template is expected to support.

Electron Fiddle is the closer alternative, and the difference is real

The README itself points to two other tools, and both are worth weighing against a git clone.

Electron Fiddle, linked at electronjs.org/fiddle, is described as "an app to test small Electron experiments." The difference in approach is where the code lives. Fiddle keeps the main process, renderer and preload in editor panes inside a desktop application, runs them without a local project directory, and can export the result to a project. minimal-repro keeps the code in a git repository that you clone, edit in your own editor and push. If your goal is to attach a link to an issue, the repository is the more portable artifact, because it works with the reviewer's existing tooling and version control. If your goal is to try six variations of a main process call in ten minutes, Fiddle skips the filesystem entirely.

Electron Forge is the other link, aimed at the opposite problem: starting a real application. It is not an alternative for reproducing a bug, it is the thing you graduate to once the bug is fixed and you need a build pipeline. Choosing between them is a question of whether you are producing evidence or producing a product.

Licence, maintenance and what an upgrade costs

The repository is licensed CC0-1.0, the public domain dedication, and package.json repeats "license": "CC0-1.0" with LICENSE.md at the root. For a template that people copy into issue threads, that is permissive in the practical sense: there is no attribution requirement to satisfy when you paste the contents into a bug report. It is not legal advice, and anyone embedding the code in a commercial product should read the licence text themselves rather than take this paragraph as a clearance.

Upgrade cost is close to zero by construction. There is one dependency, electron ^45.0.0, and one script. Bumping the version means editing one line in package.json and reinstalling. There is no plugin API to track and no configuration schema to migrate.

The maintenance question is different from the upgrade question. The last push was on 2026-10-28, and the repository is not archived. What the README does not document is a support policy, a release cadence or a compatibility matrix, and the repository has no published releases. Treat it as a stable, small artifact rather than a project with a roadmap.

Editorial conclusion

Adopt electron/minimal-repro when you need to hand a maintainer a runnable Electron case rather than a description, and when the bug survives inside a four-file app with electron ^45.0.0 as its only dependency. Do not adopt it to bootstrap a product: the README points at Electron Forge for that, and the template ships without packaging, signing or auto-update. Before you file anything, verify that the behaviour still happens after you strip the repro down to main.js, preload.js, index.html and renderer.js, because every extra line is a line a maintainer has to read past.

Frequently asked questions

Official sources

1. electron/minimal-repro on GitHub
2. Issues
3. License: CC0-1.0
4. Project website
5. README