- Contribution policy
- Adding a new package
- Code style
- Generated code
- Tests
- Adding or changing a feature
- Commit style
- Pull requests
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC2119, and RFC8174 when, and only when, they appear in all capitals, as shown here.
Core mason.nvim package definitions reside within the github:mason-org/mason-registry
registry. Contributions to add new packages MUST be done there (refer to
the README and existing package definitions).
This project adheres to Editorconfig, Selene, and Stylua code style & formatting rules. New patches MUST adhere to these coding styles.
Some changes such as adding or changing a package definition will require generating some new code. The changes to generated code MAY be included in a pull request. If it's not included in a pull request, it will automatically be generated and pushed to your branch before merge.
Generating code can be done on Unix systems like so:
make generateTests MAY be added or modified to reflect any new changes. Tests can be executed on Unix systems like so:
make test
FILE=tests/mason-core/managers/luarocks_spec.lua make testAdding or changing a feature MUST be preceded with an issue where scope and acceptance criteria are agreed upon with project maintainers before implementation.
Commits SHOULD follow the conventional commits guidelines.
Once a pull request is marked as ready for review (i.e. not in draft mode), new changes SHOULD NOT be force-pushed to the branch. Merge commits SHOULD be preferred over rebases.