Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/eden-emulator/mirror/llms.txt

Use this file to discover all available pages before exploring further.

Pull requests are the primary way code enters Eden. Before submitting one, it is worth understanding who merges PRs, how they must be named, and where discussions happen so your contribution moves through review efficiently.

​
PR process

Only core developers may merge pull requests, and they do so only after a PR has been properly tested and any open discussions on Discord or Stoat have concluded. Labels are recommended but not required. All PRs must be namespaced. Typing is optional but encouraged.

​
PR naming convention

PR titles follow a namespaced format, optionally with a conventional-commit type: 
[namespace] type: short description

[namespace] short description

​
Examples

[cmake] refactor: CPM over submodules
[desktop] feat: implement firmware install from ZIP
[hle] stub fw20 functions
[core] test: raise maximum CPU cores to 6
[cmake, core] Unbreak FreeBSD Building Process
The type token (e.g. feat, fix, refactor, test, docs) is optional but helps reviewers understand the nature of a change at a glance.

​
Namespacing rules

Namespaces identify the part of the codebase a PR touches. The following conventions apply:
  • Committer’s choice. The level of namespacing is generally up to the author.
  • Two levels maximum — except in [hle], where you may use up to four levels to reflect the specificity of the HLE subsystem change (e.g. [hle/nfc/amiibo]).
  • Up to two extra namespaces may be added for clarity when a change spans multiple areas (e.g. [cmake, core]).
  • Project-wide changes (excluding CMake changes) should use [meta].
  • Maintainers may adjust namespaces at their discretion after submission.
  • Commits within a PR do not need to be namespaced, though it is recommended.
The commit message style inside a PR does not need to match the PR title exactly, but it is good practice to keep individual commit messages descriptive and consistent.

​
How to get started

1

Fork the repository

Visit the Eden repository at git.eden-emu.dev/eden-emu/eden and fork it to your account. If you do not yet have an account, see Getting a Git account.
2

Create a branch

Work on a dedicated branch — never commit directly to master:
git checkout -b feat/my-feature
3

Make and test your changes

Follow the development guidelines for license headers, IDE setup, and any relevant coding conventions. See Debugging and testing for how to validate your changes.
4

Push and open a PR

Push your branch and open a pull request against master at git.eden-emu.dev/eden-emu/eden. Give it a title that follows the naming convention above.

​
Communication

Discussions about PRs take place in two main channels:
  • Discord — discord.gg/HstXbPch7X for real-time discussion with developers and testers.
  • Stoat — the project’s internal communication platform for asynchronous coordination among core developers.
If your PR has been open for a while with no response, reaching out on Discord is the fastest way to get attention from a reviewer.

Build docs developers (and LLMs) love

Get started for freeTalk to us