Skip to content

Latest commit

 

History

History
62 lines (45 loc) · 3.06 KB

CONTRIBUTING.md

File metadata and controls

62 lines (45 loc) · 3.06 KB
Raw

Contributor Guidelines

We are happy to accept contributions to this project! See the setup section for getting started. We try to follow the conventional commits practice wherever possible.

Setup

pre-commit

Most users will want to run pre-commit install to ensure the commit hooks are installed. You will need both stylua and luacheck installed for these checks to work.

If you are using nix and direnv, you can simply alternatively run direnv allow, which will install all the underyling dependencies.

VSCode

The .vscode/ folder has settings and extension recommendations. It is best to install these to avoid run into linting errors only when making a commit.

Conventional Commits

Do your best to follow the default set of conventional commits naming, as described here. The following is a brief summary of what category you should use, if you aren't exactly sure which label to use.

  • fix: Commits related to fixing bugs or errors in the codebase.
  • feat: Commits related to adding new features or functionality to the project.
  • build: Commits related to build system or external dependencies (e.g., flake.nix).
  • chore: Commits related to chores (e.g., linting), maintenance tasks, or general upkeep of the project that do not fit into other categories.
  • ci: Commits related to continuous integration configuration and scripts.
  • docs: Commits related to documentation (e.g., README, API documentation, inline code comments).
  • style: Commits related to code style, formatting, or whitespace changes; no production code change.
  • refactor: Commits that neither fix a bug nor add a feature but make changes to the codebase (e.g., renaming a variable, deleting code). If your cleanup includes additional inline doc changes, still include it under refactor.
  • perf: Commits related to performance improvements.
  • test: Commits related to adding missing tests or correcting existing tests.

Linting

We make use of pre-commit. See earlier for installation steps. Below are some tips about how to work around common linting errors you may run into, but can't actually fix.

luacheck

Sometimes you'll get a warning for something that isn't valid. A good example of this is getting a warning for a line being too long, when the line is a URI that you can't shorten. In this case you can use the inline command functionality to disable a check for a specific line.

For example:

-- luacheck:ignore 631
-- https://github.com/nvim-treesitter/nvim-treesitter-textobjects/blob/master/lua/nvim-treesitter/textobjects/select.lua#L114