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.
- Follow the Installation guide
- Link your fork with the repository
git remote add upstream https://github.com/lunarvim/LunarVim.git
, or usegh fork
- That's it! You can now
git fetch upstream
andgit rebase [-i] upstream/rolling
to update your branches with the latest contributions.
- Formatter: shfmt.
- Linter: shellcheck.
Install pre-commit which will run all linters and formatters for you as a pre-commit-hook.
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 .
- To avoid duplicate work, create a draft pull request.
- Your PR must pass all the automated-ci-tests.
- Use a git-feature-branch instead of the master/rolling branch.
- Use a rebase-workflow.
- 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
- 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
Name your branches meaningfully.
ex)
(feature|bugfix|hotfix)/what-my-pr-does
Members of the community have multiple ways to collaborate on the project. We encourage you to join the community: