Contributing to obsidian.nvim
July 2, 2026 ยท View on GitHub
Thanks for considering contributing! Please read this document to learn the various steps you should take before submitting a pull request.
TL;DR
- Start an issue to discuss the planned changes
- To submit a pull request
- Start developing your feature in a branch
- Make sure that your codes complies the
obsidian.nvimcode style, runmake chores - The PR should contain
- The code changes
- Tests for the code changes
- Documentation for the code changes (in the code itself and in the
README.md) CHANGELOG.mdentry for the code changes
Details
Note: we automate tedious tasks using a Makefile in the root of the repository.
Just call make to see what you can do, or make chores to run the most important tasks on your code.
If you don't want to install the dependency need for some of the checks, you can also just open a PR to leverage GitHub actions for the check.
Keeping the CHANGELOG.md up-to-date
This project maintains a CHANGELOG
with a format based on Keep a Changelog.
If your PR addresses a bug or makes any other substantial change,
please be sure to add an entry under the "Unreleased" section at the top of CHANGELOG.md.
Entries should always be in the form of a list item under a level-3 header of either "Added", "Fixed", "Changed", or "Removed" for the most part.
If the corresponding level-3 header for your item does not already exist in the "Unreleased" section, you should add it.
Formatting code
TL;DR: make style
Lua code should be formatted using StyLua.
Once you have StyLua installed, you can run make style to automatically apply styling to all of the Lua files in this repo.
Linting code
TL;DR: make lint
- We use selene to lint the Lua code and typos to catch typos.
- Once you have
seleneandtyposinstalled, you can runmake lintto get a report.
Checking types
TL;DR: make types
- We use EmmyLua Analyzer Rust to check the type annotations in the lua code.
- Contributions should have type annotations.
Running tests
TL;DR: make test
- Tests are written in the
tests/folder and are run using mini.test. The make command will download the dependencies for you.- For a reference of using mini.test, see this guide.
- For async tests, use the helpers in
tests/helpers.lua:h.child_await(child, lua, { desc = "..." })for callback-style child-Neovim async code.h.child_wait(child, lua, { desc = "..." })or focused helpers likeh.child_wait_for_buf_name()for eventual child state.- Avoid raw
vim.wait()and fixed sleeps in tests; always wait for a specific condition with a timeout message.
Building the vim user documentation
TL;DR: make user-docs
- The Vimdoc help lives at
doc/obsidian.txt, which is automatically generated from theREADME.mdusing markdoc - Please only commit documentation changes to the
README.md, notdoc/obsidian.txt. - This step don't need to be done locally since CI will auto run.
Building the vim API documentation
TL;DR: make api-docs
- The API docs lives in
doc/obsidian_api.txtand is generated from the source code usingmini.docs. - This step don't need to be done locally since CI will auto run.
Contribute to the user wiki
See Edit user wiki