Skip to content

Latest commit

 

History

History
116 lines (83 loc) · 4.1 KB

CONTRIBUTING.md

File metadata and controls

116 lines (83 loc) · 4.1 KB
Raw

Contributing to LunarVim

Welcome to the LunarVim contributing guide. We are excited about the prospect of you joining our community!

There are many opportunities to contributing to the project at any level. Every contribution is highly valued and no contribution is too small.

You do not need to write code to contribute to this project. Documentation, demos, and feature design advancements are a key part of this project's growth.

One of the best ways to begin contributing in a meaningful way is by helping find bugs and filing issues for them.

Getting Started

  1. Follow the Installation guide
  2. Link your fork with the repository git remote add upstream https://github.com/lunarvim/LunarVim.git, or use gh fork
  3. That's it! You can now git fetch upstream and git rebase [-i] upstream/rolling to update your branches with the latest contributions.

Setting up development tools

For editing Lua files

  1. Formatter: stylua.
  2. Linter: luacheck.

For editing shell scripts

  1. Formatter: shfmt.
  2. Linter: shellcheck.

(Optional)

Install pre-commit which will run all linters and formatters for you as a pre-commit-hook.


Code Conventions

All lua code is formatted with Stylua.

# configurations are already stored in .stylua.toml
stylua -c .

All shell code is formatted according to Google Shell Style Guide

  • use two spaces instead of tabs
shfmt -i 2 -ci -bn -l -d .

Pull Requests (PRs)

Commit Messages

  • Commit header is limited to 72 characters.
  • Commit body and footer is limited to 100 characters per line.

Commit header format:

<type>(<scope>?): <summary>
  │       │           │
  │       │           └─> Present tense.     'add something...'(O) vs 'added something...'(X)
  │       │               Imperative mood.   'move cursor to...'(O) vs 'moves cursor to...'(X)
  │       │               Not capitalized.
  │       │               No period at the end.
  │       │
  │       └─> Commit Scope is optional, but strongly recommended.
  │           Use lower case.
  │           'plugin', 'file', or 'directory' name is suggested, but not limited.
  │
  └─> Commit Type: build|ci|docs|feat|fix|perf|refactor|test
Commit Type Guideline
  • build: changes that affect the build system or external dependencies (example scopes: npm, pip, rg)
  • ci: changes to CI configuration files and scripts (example scopes: format, lint, issue_templates)
  • docs: changes to the documentation only
  • feat: new feature for the user
  • fix: bug fix
  • perf: performance improvement
  • refactor: code change that neither fixes a bug nor adds a feature
  • test: adding missing tests or correcting existing tests
  • chore: all the rest, including version bump for plugins

Real world examples:

feat(quickfix): add 'q' binding to quit quickfix window when focused

fix(installer): add missing "HOME" variable

Branch Naming

Name your branches meaningfully.

ex) (feature|bugfix|hotfix)/what-my-pr-does


Communication

Members of the community have multiple ways to collaborate on the project. We encourage you to join the community: