How to contribute
Bug reports, pull requests and releasing.
Thanks for helping out! Bug reports, fixes, features and documentation are all welcome.
- Development setup: build the plugin and run your checkout.
- Testing: the test suites and how to write tests.
- Architecture: how the editor, the server and the page fit together, and where to make a change.
Reporting a bug
Open an issue with:
- your editor and its version (
nvim --versionorvim --version) and your system - the output of
:checkhealth mkdp(Neovim) - a small markdown file and the configuration that show the problem
- the log, ideally with
NVIM_MKDP_LOG_LEVEL=debug
Before you start
For anything larger than a small fix, open an issue first so we can agree on
the approach. UPSTREAM_ISSUES.md triages the
issues of the original plugin, and
skip-test-case.md lists the known gaps in the
tests; both are good places to find work.
Pull requests
- Target the
masterbranch. - Keep pull requests focused on one change.
- Add or update tests: a fix comes with a test that fails without it, see Testing.
- Run
./test.shand the checks. - Describe what you changed and how you tested it.
- Add an entry to
CHANGELOG.mdunderUnreleasedfor user-facing changes. - Update the documentation for anything users see, see Working on the docs. New options go in the configuration reference; a test checks that every option is documented.
Releasing
For maintainers:
- Bump
versioninCargo.tomland renameUnreleasedinCHANGELOG.mdto the new version. - Run
./test.sh, and the manual checks. - Commit and push to
master. - Run
./release.sh. It tags the version fromCargo.tomland pushes the tag, and the release workflow builds the binaries and publishes the GitHub release.
The plugin installs the release matching its Cargo.toml version, so the tag
must exist before users update: lazy.nvim runs build.lua on update, other
plugin managers run mkdp#util#install_sync() from their build hook, and
:MarkdownPreview downloads the binary when it does not match the plugin.