Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
85 lines (61 loc) · 2.86 KB

CONTRIBUTING.md

File metadata and controls

85 lines (61 loc) · 2.86 KB

Contributing to Neo-tree

Contributions are welcome! To keep everything clean and tidy, please follow the guidelines below.

Development setup

View mise.toml for tasks and their implementation.

# Install/update dependencies
mise deps
# Or `mise update-dependencies`

# Run stylua
mise format

# Do a lua-language-server pass
mise luals-check

# Do a emmylua-analyzer-rust pass (not important for now)
mise luals-check

# Tests
mise test

# Tests in Docker (for better sandboxing)
mise test-docker

Code Style

This is open for debate, but here is the current style choices being observed:

  • snake_case for all variables and functions
  • unless it is a class, then use PascalCase
  • other OOP things, like method names should use camelCase
  • BUT we don't currently have any OOP parts and I don't think we want any

StyLua

We use (StyLua)[https://github.com/JohnnyMorganz/StyLua] to enforce consistency in code. You should install it on your local machine. PRs will be checked with this tool.

Commit Messages

We use semantic, aka conventional commit messages. The official guide can be found here: https://www.conventionalcommits.org/en/v1.0.0/

You can also just take a look at the commit history to get the idea. The optional scope for this project would usually be the source, i.e. feat(filesystem): add awesome feature that does xyz.

Branching

The default branch is set to main and all Pull Requests should target this branch. After a short testing period, it will be merged to the current release branch.

This project requires a linear history. I don't trust merge commits. This means you will have to rebase your branch on main before the pull request can be merged. This can get a bit annoying in a busy repository, but I think it is worth the effort.

Documentation

All new features should be documented in the commit they were added in. The current strategy is to maintain:

  • Config Options: added to defaults and described in comments. This is the bare minimum documentation for an option.
  • The README contains "back of the box" high level overview of features. It is meant for people trying to decide if they want to install this plugin or not. It should include references to the help file for more information: :h neo-tree-setup
  • Whether something should be mentioned in the README or just in the help file is a completely subjective judgement call that is made on a case by case basis based on how many people are likely to be interested in that information.
  • The vim help file doc/neo-tree.txt is the definitive reference and should contain all information needed to configure and use the plugin.
  • OUR DOCUMENTATION IS NOT GOOD ENOUGH! Consider the current level of documentation the bare minumum and not the ideal. More documentation would be greatly appreciated.