673351b6a1* build: replace eslint with oxlint and add oxfmt Replace ESLint and its plugin ecosystem with oxlint (oxc.rs). Add oxfmt alongside oxlint for JS/TS formatting and import sorting. - Consolidate root .eslintrc.json plus 13 nested configs into .oxlintrc.json - script/lint.js spawns oxlint binary directly instead of ESLint Node API - Per-process no-restricted-imports rules preserved as oxlintrc overrides - mocha/no-exclusive-tests replaced by in-repo plugin (no-only-tests.mjs) - docs ESLint pass replaced by inline node: protocol check in lint.js - .oxfmtrc.json matching repo style (single quotes, semicolons, 2-space) - yarn lint:fmt (oxfmt --check) chained into yarn lint - yarn format (oxfmt --write) for local fixup - lint-staged runs oxfmt --write on staged JS/TS files This commit contains only rule/tooling infrastructure changes and is intended to be cherry-picked to other maintenance branches, where formatting and lint fixes can be applied separately. Manual backport of electron/electron@e1af67c698 (#50691) and electron/electron@3c7fd34f47 (#50692). * chore: apply oxfmt formatting and oxlint fixes One-time application of the new linting and formatting rules to the 42-x-y codebase: - yarn format (oxfmt --write) over all JS/TS sources - oxlint --fix to restore curly braces where oxfmt removed them - Prefix unused parameters with _ (no-unused-vars) - Add eslint-disable-next-line comments for intentional patterns: - prefer-promise-reject-errors in desktop-capturer.ts - no-throw-literal in preload.ts Pure formatting and lint suppression; no behavioral changes. |
||
|---|---|---|
| .. | ||
| api-history-migration-guide.md | ||
| build-instructions-gn.md | ||
| build-instructions-linux.md | ||
| build-instructions-macos.md | ||
| build-instructions-windows.md | ||
| chromium-development.md | ||
| clang-tidy.md | ||
| coding-style.md | ||
| creating-api.md | ||
| debugging-on-macos.md | ||
| debugging-on-windows.md | ||
| debugging-with-symbol-server.md | ||
| debugging-with-xcode.md | ||
| debugging.md | ||
| issues.md | ||
| patches.md | ||
| pull-requests.md | ||
| README.md | ||
| reclient.md | ||
| source-code-directory-structure.md | ||
| style-guide.md | ||
| testing.md | ||
| v8-development.md | ||
Developing Electron
These guides are intended for people working on the Electron project itself. For guides on Electron app development, see /docs/README.md.
Table of Contents
- Issues
- Pull Requests
- Documentation Styleguide
- Source Code Directory Structure
- Coding Style
- Using clang-tidy on C++ Code
- Build Instructions
- Chromium Development
- V8 Development
- Testing
- Debugging
- Patches
Getting Started
In order to contribute to Electron, the first thing you'll want to do is get the code.
Electron's build-tools automate much of the setup for compiling Electron from source with different configurations and build targets.
If you would prefer to build Electron manually, see the build instructions.
Once you've checked out and built the code, you may want to take a look around the source tree to get a better idea of what each directory is responsible for. The source code directory structure gives a good overview of the purpose of each directory.
Opening Issues on Electron
For any issue, there are generally three ways an individual can contribute:
- By opening the issue for discussion
- If you believe that you have found a new bug in Electron, you should report it by creating a new issue in
the
electron/electronissue tracker.
- If you believe that you have found a new bug in Electron, you should report it by creating a new issue in
the
- By helping to triage the issue
- You can do this either by providing assistive details (a reproducible test case that demonstrates a bug) or by providing suggestions to address the issue.
- By helping to resolve the issue
- This can be done by demonstrating that the issue is not a bug or is fixed;
but more often, by opening a pull request that changes the source in
electron/electronin a concrete and reviewable manner.
- This can be done by demonstrating that the issue is not a bug or is fixed;
but more often, by opening a pull request that changes the source in
See issues for more information.
Making a Pull Request to Electron
Most pull requests opened against the electron/electron repository include
changes to either the C/C++ code in the shell/ folder,
the TypeScript code in the lib/ folder, the documentation in docs/,
or tests in the spec/ folder.
See pull requests for more information.
If you want to add a new API module to Electron, you'll want to look in creating API.
Governance
Electron has a fully-fledged governance system that oversees activity in Electron and whose working groups are responsible for areas like APIs, releases, and upgrades to Electron's dependencies including Chromium and Node.js. Depending on how frequently and to what end you want to contribute, you may want to consider joining a working group.
Details about each group and their responsibilities can be found in the governance repo.
Patches in Electron
Electron is built on two major upstream projects: Chromium and Node.js. Each of these projects has several of their own dependencies, too. We try our best to use these dependencies exactly as they are but sometimes we can't achieve our goals without patching those upstream dependencies to fit our use cases.
As such, we maintain a collection of patches as part of our source tree. The process for adding or altering one of these patches to Electron's source tree via a pull request can be found in patches.
Debugging
There are many different approaches to debugging issues and bugs in Electron, many of which are platform specific.
For an overview of information related to debugging Electron itself (and not an app built with Electron), see debugging.