electron/electron: the root package is a build harness, Chromium is vendored and patched, and lint runs four toolchains

The shipped package lives in npm/, and the root manifest is a private build harness

The root package.json is named for continuous integration, not for users. Its name is the CI dev root, its version is the placeholder string 0.0.0-development, and it is marked private. The directory that becomes the package people install is npm/, and the readme's installation instruction installs the framework as a development dependency, which is what the text calls the preferred method.

npm install electron --save-dev

Consequence for the reader: nothing in the root manifest tells you which Electron you are working on, because the version is generated by a script in the script directory rather than typed into the file, and a contributor who greps the manifest for a version number finds a placeholder. It also means every contributor's checkout installs a set of cloud and CI packages, storage and telemetry clients, and a native build tool, none of which end up in a user's application.

Requiring electron from plain Node hands you a path, not a runtime

The programmatic usage section explains a behaviour that catches people out. If you require the module inside your Node application rather than inside your Electron application, the value you get back is the file path to the binary, and you are meant to spawn it.

const electron = require('electron')
const proc = require('node:child_process')

// will print something similar to /Users/maf/.../Electron
console.log(electron)

// spawn Electron
const child = proc.spawn(electron)

Consequence for the reader: the same import means two different things depending on which process evaluates it, so a script, a test runner, or a bundler that resolves it in the wrong context gets a string and fails later, when something tries to execute a path that is not what you expected. The readme also lists a mirror for China and points at advanced installation instructions for a custom mirror, because the default install fetches a binary rather than only JavaScript.

Chromium is vendored, patched, and linted from inside this repository

The tree carries a vendored Chromium in chromium_src/, a dependency manifest named DEPS, a patches directory, a GN build file, and several generated file lists including auto-generated ones and separate ones for spelling and for two C++ standard library variants. There is also a directory of build flags, a lint roller configuration, and a lint step in the manifest whose name refers to rolling lint into Chromium. Consequence for the reader: an Electron version is a Chromium version plus a set of local patches, and the readme says in general terms that Electron tries to align with Chromium on platform support, which means the floor for macOS and Windows is set by the browser underneath rather than by a decision the desktop project makes. Anyone planning a long-lived application is planning around two upstream cadences, not one.

Five tsconfig files mark five separate TypeScript programs

The root holds tsconfig.json plus four more, one for the Electron sources, one for scripts, one for the spec suite, and one for the default application, and the tree is split to match with lib/, script/, spec/, default_app/, npm/, and a typings directory. The formatting script in the manifest walks the same seven directories in one glob. Consequence for the reader: the repository is not one type-checked project, so whether a type error is caught depends on which program boundary the offending file sits behind, and an import that crosses a boundary is a configuration decision rather than something a developer chooses at the call site. It also means a clean type check in one of those programs says little about the others.

Four lint toolchains run in one chained command, and one of them can rewrite files

The lint script chains four steps: a node script that runs the main checks, a formatting check, a documentation check, and the Chromium roller check. Underneath sit an oxlint configuration and an oxfmt configuration for JavaScript and TypeScript, a clang format and a clang tidy configuration for the native side, and two markdownlint configurations, one of which is named as an autofix configuration. The clang format check is a python script pointed at the shell directory, and the web side formatting check walks a single glob over the lib, spec, script, build, default_app, npm, and typings directories.

Consequence for the reader: the native formatting rule is scoped to the shell directory, so C++ elsewhere is covered by a different path or not by this command at all, and an autofix documentation configuration means running lint in a repository that is mostly C++ can rewrite Markdown files under your hands. The strictness you get from a green lint run depends on which of the four steps you actually ran.

The release token is named once, in an example env file

There is one environment file at the root and it holds one variable. Its comment says these variables are only necessary for creating Electron releases, points at a releasing document in the development docs, and the variable is a GitHub token with an empty value.

Consequence for the reader: the path from a commit to a published build depends on a credential the project keeps out of the repository, and the only place in the tree that names it is a file whose purpose is to be copied, so a contributor reading the readme will not find it. The manifest also shows the shape of the release tooling, with a GitHub API client, a storage blob client, a telemetry client, and a release CLI pinned to one exact version while almost everything else uses a range. Meanwhile the release list shows two patch lines landing on the same day, v44.5.0 and v43.7.6 on 2026-09-29, followed by v44.5.1 on 2026-09-30, which is what shipping two supported lines looks like from the outside.

Eight badge locales and seven accepted languages in the same file

Near the top, a line lists available translations as flag badges covering Chinese, Brazilian Portuguese, Spanish, Japanese, Russian, French, English, and German, and says the other versions live on the Crowdin project. Near the bottom, a translations section says the project currently accepts translations for Simplified Chinese, French, German, Japanese, Portuguese, Russian, and Spanish. Consequence for the reader: the two lists in the same file do not match, and an English badge appears where the accepted list has no English entry, so a reader looking for the Brazilian or the European Portuguese translation has no way to tell from the readme which one exists. The readme also carries terms you have to honour rather than just read: the Contributor Covenant with an address for reporting unacceptable behaviour, and a requirement to follow the OpenJS Foundation trademark policy when using the Electron logos.

Editorial conclusion

Use electron/electron when you are shipping a desktop application and you have decided that carrying a browser and a Node runtime in your binary is the right trade, because that is the design and the alternative frameworks in the market are built on a different assumption. Do not install it as a runtime dependency, since the readme's own instruction is to add it as a development dependency and the build only exists on your machine. Before you commit, check four things: which platform versions you need, because support tracks Chromium and the readme says so plainly, so a platform can be dropped when Chromium drops it; how you will get binaries in regions where the default download is slow, since a mirror is a documented but separate step; what the module returns when you require it from plain Node, because it is a path to a binary rather than the runtime; and, if you maintain the repository itself, that your toolchain and Node version match what the pinned configuration files expect, since the build is strict about that.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes