2.6 KiB
Contributing
Adding a port
Create a file in modules/<module>/
with the name of the port. All ports should have
the catppuccin.enable
and catppuccin.flavour
options, and optionally the
catppuccin.accent
option. catppuccin.flavour
and catppuccin.accent
should
default to config.catppuccin.flavour
and config.catppuccin.accent
, respectively.
nvfetcher is used to track our upstream sources to use in modules. This allows us to easily access and auto-update all themes. Most repositories can be specified like so:
[program_name]
src.git = "https://github.com/catppuccin/program_name.git"
fetch.github = "catppuccin/program_name"
After creating your module, add the options to enable it in test.nix
under the
nodes.machine
attrset. This will allow for your configuration to be tested along
with the other modules in a VM automatically.
Commits that add ports should be of the format
feat(<nixos or home-manager>): add support for <port>
Note
Unofficial ports will not be accepted; all sources must be from the Catppuccin GitHub organization
Commit messages
This repository uses Conventional Commits. Commit headers should be lowercase. Most commits should include a body that briefly describes the motivation and content of the commit.
Commit types
fix
: A bug fix that doesn't modify the public APIfeat
: A code change that modifies the public APIrefactor
: A code change that doesn't change behaviorstyle
: A style fix or changedocs
: Any change to documentationci
: Any change to CI filesrevert
: A revert commit. The message should describe the reasoning and the commit should include theRefs:
footer with the short hashes of the commits being reverted.chore
: catch-all type
Commit scopes
Available commit scopes are port names, nixos
, home-manager
, and modules
. If
none of these apply, omit the scope.
Breaking changes
All breaking changes should be documented in the commit footer in the format
described by Conventional Commits. Use the <type>!
syntax in order to distinguish
breaking commits in the log, but include the footer to provide a better description
for the changelog generator.
feat(bar)!: foo the bars
BREAKING CHANGE: bars are now foo'ed
For Maintainers
Use squash merges when reasonable. They don't pollute the log with merge commits, and unlike rebase merges, list the author as the committer as well.