# Guidelines {#sec-guidelines}

If your contribution satisfy the following rules then there is a good
chance it will be merged without too much trouble. The rules are
enforced by the Home Manager maintainers and to a lesser extent the Home
Manager CI system.

If you are uncertain how these rules affect the change you would like to
make then feel free to start a discussion in the
[#home-manager](https://webchat.oftc.net/?channels=home-manager) IRC
channel, ideally before you start developing.

## Maintain backward compatibility {#sec-guidelines-back-compat}

Your contribution should not cause another user's existing configuration
to break unless there is a very good reason and the change should be
announced to the user through an
[assertion](https://nixos.org/manual/nixos/stable/index.html#sec-assertions)
or similar.

Remember that Home Manager is used in many different environments and
you should consider how your change may effect others. For example,

-   Does your change work for people that do not use NixOS? Consider
    other GNU/Linux distributions and macOS.

-   Does your change work for people whose configuration is built on one
    system and deployed on another system?

## Keep forward compatibility in mind {#sec-guidelines-forward-compat}

The master branch of Home Manager tracks the unstable channel of
Nixpkgs, which may update package versions at any time. It is therefore
important to consider how a package update may affect your code and try
to reduce the risk of breakage.

The most effective way to reduce this risk is to follow the advice in
[Add only valuable options](#sec-guidelines-valuable-options).

## Add only valuable options {#sec-guidelines-valuable-options}

When creating a new module it is tempting to include every option
supported by the software. This is *strongly* discouraged. Providing
many options increases maintenance burden and risk of breakage
considerably. This is why only the most [important software
options](https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md#valuable-options)
should be modeled explicitly. Less important options should be
expressible through an `extraConfig` escape hatch.

A good rule of thumb for the first implementation of a module is to only
add explicit options for those settings that absolutely must be set for
the software to function correctly. It follows that a module for
software that provides sensible default values for all settings would
require no explicit options at all.

If the software uses a structured configuration format like a JSON,
YAML, INI, TOML, or even a plain list of key/value pairs then consider
using a `settings` option as described in [Nix RFC
42](https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md).

These guidelines describe the minimum option design requirements. Before
submitting a module, compare it against the upstream documentation or
source code and verify that the generated files, services, environment
variables, and command line arguments all match the upstream behavior
you intend to expose.

If a module installs a package, try to make the package option nullable,
for example

``` nix
package = lib.mkPackageOption pkgs "xdg-terminal-exec" { nullable = true; };
```

This lets users keep installation outside Home Manager, for example via
`apt` or because the program is built into macOS, while still using the
module for configuration. Keeping the package non-nullable is fine when
the enabled behavior structurally requires the executable or when
package-less support would make the module significantly more complex.

Avoid generating files for empty settings, null packages, or optional
features that are not configured.

If upstream does not use XDG paths by default but supports changing the
configuration location with an environment variable, for example
`FOO_HOME`, expose a `configDir` option and use it to respect
`home.preferXdgDirectories`.

## Add relevant tests {#sec-guidelines-add-tests}

If at all possible, make sure to add new tests and expand existing tests
so that your change will keep working in the future. See
[Tests](tests.md#sec-tests) for more information about the Home Manager test
suite.

All contributed code *must* pass the test suite.

## Add relevant documentation {#sec-guidelines-module-maintainer}

Many code changes require changing the documentation as well. The
documentation is written in
[Nixpkgs-flavoured Markdown](https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-markup).
All text is hosted in Home Manager's Git repository.

The HTML version of the manual containing both the module option
descriptions and the documentation of Home Manager can be generated and
opened by typing the following in a shell within a clone of the Home
Manager Git repository:

``` shell
$ nix-build -A docs.html
$ xdg-open ./result/share/doc/home-manager/index.html
```

When you have made changes to a module, it is a good idea to check that
the man page version of the module options looks good:

``` shell
$ nix-build -A docs.manPages
$ man ./result/share/man/man5/home-configuration.nix.5
```

## Module Auto-importing {#sec-module-auto-importing}

Home Manager automatically imports all modules from the `modules/programs/` and
`modules/services/` directories. This auto-importing behavior follows these
rules:

- **Nix files**: All `.nix` files in these directories are automatically
  imported
- **Directories**: All subdirectories are automatically imported (typically
  containing a `default.nix` file)
- **Exclusions**: Files and directories starting with an underscore (`_`) are
  excluded from auto-importing

This allows for flexible module organization:

```
modules/programs/
├── git.nix              # Single-file module (imported)
├── firefox/             # Multi-file module (imported)
│   ├── default.nix
│   └── addons.nix
├── _experimental.nix    # Excluded (starts with _)
└── _wip/                # Excluded directory (starts with _)
    └── newfeature.nix
```

When adding a new module, simply place it in the appropriate directory
(`programs/` for user programs, `services/` for user services) and it will be
automatically discovered and included in the Home Manager module system.

## Add yourself as a module maintainer {#_add_yourself_as_a_module_maintainer}

Every new module *must* include a named maintainer using the
`meta.maintainers` attribute. If you are a user of a module that
currently lacks a maintainer then please consider adopting it.

If you are present in the nixpkgs maintainer list then you can use that
entry. If you are not then you can add yourself to
`modules/lib/maintainers.nix` in the Home Manager project.

As a maintainer you are expected to respond to issues and
pull-requests associated with your module.

Maintainers are encouraged to join the IRC or Matrix channel and
participate when they have opportunity.

## Format your code {#sec-guidelines-code-style}

Make sure your code is formatted as described in [Code
Style](#sec-code-style). To maintain consistency throughout the project
you are encouraged to browse through existing code and adopt its style
also in new code.

## Format your commit messages {#sec-guidelines-commit-message-style}

Similar to [Format your code](#sec-guidelines-code-style) we encourage a
consistent commit message format as described in
[Commits](#sec-commit-style).

## Format your news entries {#sec-guidelines-news-style}

If your contribution includes a change that should be communicated to
users of Home Manager then you can add a news entry. The entry must be
formatted as described in [News](news.md#sec-news).

When new modules are added a news entry should be included.

News entries and release notes serve different purposes. Release notes
should be updated separately when a change affects users migrating
between stable releases, such as state version default changes, required
migration steps, or broad behavior changes. See
[Release Notes](release-notes.md#sec-contributing-release-notes) and [News](news.md#sec-news)
for more details.

## Use conditional modules and news {#sec-guidelines-conditional-modules}

Home Manager includes a number of modules that are only usable on some
of the supported platforms. The most common example of platform specific
modules are those that define systemd user services, which only works on
Linux systems.

If you add a module that is platform specific then make sure the module
guards platform-specific configuration with an appropriate condition, for
example `pkgs.stdenv.hostPlatform.isLinux` or
`pkgs.stdenv.hostPlatform.isDarwin`. Modules in `modules/programs/` and
`modules/services/` are auto-imported, so the platform condition should live
in the module behavior and in any platform-specific tests rather than in a
separate module discovery call.

Similarly, if you are adding a news entry then it should be shown only
to users that may find it relevant, see [News](news.md#sec-news) for a
description of conditional news.

## Mind the license {#sec-guidelines-licensing}

The Home Manager project is covered by the MIT license and we can only
accept contributions that fall under this license, or are licensed in a
compatible way. When you contribute self written code and documentation
it is assumed that you are doing so under the MIT license.

A potential gotcha with respect to licensing are option descriptions.
Often it is convenient to copy from the upstream software documentation.
When this is done it is important to verify that the license of the
upstream documentation allows redistribution under the terms of the MIT
license.

## Commits {#sec-commit-style}

The commits in your pull request should be reasonably self-contained,
that is, each commit should make sense in isolation. In particular, you
will be asked to amend any commit that introduces syntax errors or
similar problems even if they are fixed in a later commit.

Keep commits atomic and separated by concern. For example, a new
maintainer entry should be a separate first commit, and a shared module
should be committed separately from integrations in existing modules.
Pull requests should not include merge commits or fixup commits.

The commit messages should follow the [seven
rules](https://chris.beams.io/posts/git-commit/#seven-rules), except for
\"Capitalize the subject line\". We also ask you to include the affected
code component or module in the first line. That is, a commit message
should follow the template

    {component}: {description}

    {long description}

where `{component}` refers to the code component (or module) your change
affects, `{description}` is a very brief description of your change, and
`{long description}` is an optional clarifying description. As a rare
exception, if there is no clear component, or your change affects many
components, then the `{component}` part is optional. See
[example_title](#ex-commit-message) for a commit message that fulfills
these requirements.

## Example commit {#ex-commit-message}

The commit
[69f8e47e9e74c8d3d060ca22e18246b7f7d988ef](https://github.com/nix-community/home-manager/commit/69f8e47e9e74c8d3d060ca22e18246b7f7d988ef)
contains the commit message

```

    starship: allow running in Emacs if vterm is used

    The vterm buffer is backed by libvterm and can handle Starship prompts
    without issues.
```

which ticks all the boxes necessary to be accepted in Home Manager.

Finally, when adding a new module, say `programs/foo.nix`, we use the
fixed commit format `foo: add module`. You can, of course, still include
a long description if you wish.

## Code Style {#sec-code-style}

The code in Home Manager is formatted by the [treefmt](https://treefmt.com) tool
and the formatting is checked in the pull request tests. Run `nix fmt` or
`treefmt` (with required formatters which can be found in `treefmt.toml` in your
`$PATH`) inside the project repository before submitting your pull request.

Keep lines at a reasonable width, ideally 80 characters or less. This
also applies to string literals.

We prefer `lowerCamelCase` for variable and attribute names with the
accepted exception of variables directly referencing packages in Nixpkgs
which use a hyphenated style. For example, the Home Manager option
`services.gpg-agent.enableSshSupport` references the `gpg-agent` package
in Nixpkgs.
