9.6 KiB
Contributing to Zellij
Thanks for considering contributing to Zellij!
First: if you're unsure of anything, feel free to ask on our Discord server, or on Matrix. We're a friendly and welcoming bunch!
Code of Conduct
Before contributing please read our Code of Conduct which all contributors are expected to adhere to.
Status of Code Contributions (PRs)
At the moment, the Zellij maintainers are very much overloaded implementing our Roadmap - and so while we very much welcome and appreciate the community's willingness to contribute - we are only able to accept code contributions for larger projects as they appear in said Roadmap.
For those willing to take up such large projects, aside from our enthusiasm - we can offer guidance through issues or our various chat platforms.
If you're still eager to contribute minor fixes, please note that we might take a long while to get to them until the current overload of the project subsides - hopefully in the coming months.
Building
To build Zellij, we're using cargo xtask. This is a standalone package shipped inside the repository, so you don't have to install additional dependencies.
To edit our manpage, the mandown crate (cargo install --locked mandown
) is used and the work is done on a markdown file in docs/MANPAGE.md.
Here are some of the commands currently supported by the build system:
# Format code, build, then run tests and clippy
cargo xtask
# You can also perform these actions individually
cargo xtask format
cargo xtask build
cargo xtask test
# Run Zellij (optionally with additional arguments)
cargo xtask run
cargo xtask run -l strider
# Run Clippy
cargo xtask clippy
# Install Zellij to some directory
cargo xtask install /path/of/zellij/binary
# Publish the zellij and zellij-tile crates
cargo xtask publish
# Update manpage
cargo xtask manpage
You can see a list of all commands (with supported arguments) with cargo xtask --help
. For convenience, xtask
may be shortened to x
: cargo x build
etc.
To run test
, you will need the package pkg-config
and a version of openssl
.
Running the end-to-end tests
Zellij includes some end-to-end tests which test the whole application as a black-box from the outside. These tests work by running a docker container which contains the Zellij binary, connecting to it via ssh, sending some commands and comparing the output received against predefined snapshots.
Should you be a macOS (including m1) user, please follow these commands before. (expand here):
rustup target add x86_64-unknown-linux-musl
brew install messense/macos-cross-toolchains/x86_64-unknown-linux-musl
export CC_x86_64_unknown_linux_musl=$(brew --prefix)/bin/x86_64-unknown-linux-musl-gcc
export AR_x86_64_unknown_linux_musl=$(brew --prefix)/bin/x86_64-unknown-linux-musl-ar
export CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER=$CC_x86_64_unknown_linux_musl
To run these tests locally, you'll need to have either docker
or podman
and also docker-compose
installed.
Once you do, in the repository root:
docker-compose up -d
will start up the docker containercargo xtask ci e2e --build
will build the generic linux executable of Zellij in the target folder, which is shared with the containercargo xtask ci e2e --test
will run the tests
To re-run the tests after you've changed something in the code base, be sure to repeat steps 2 and 3.
Debugging / Troubleshooting while developing
Zellij uses the excellent log
crate to handle its internal logging. The output of these logs will go to /$temp_dir/zellij-<UID>/zellij-log/zellij.log
which $temp_dir
refers to std::env::temp_dir(). On most of operating systems it points to /tmp
, but there are exceptions, such as /var/folders/dr/xxxxxxxxxxxxxx/T/
for Mac.
Example:
let my_variable = some_function();
log::info!("my variable is: {:?}", my_variable);
Note that the output is truncated at 100KB. This can be adjusted for the purposes of debugging through the LOG_MAX_BYTES
constant, at the time of writing here: https://github.com/zellij-org/zellij/blob/main/zellij-utils/src/logging.rs#L24
When running Zellij with the --debug
flag, Zellij will dump a copy of all bytes received over the pty for each pane in: /$temp_dir/zellij-<UID>/zellij-log/zellij-<pane_id>.log
. These might be useful when troubleshooting terminal issues.
Testing plugins
Zellij allows the use of the Singlepass compiler for wasmer. This can enable great gains in compilation time of plugins in detriment of stability, notably on Arm64 architectures.
To enable the singlepass compiler, use the singlepass
flag. E.g.:
cargo xtask run --singlepass
How we treat clippy lints
We currently use clippy in GitHub Actions with the default settings that report only clippy::correctness
as errors and other lints as warnings because Zellij is still unstable. This means that all warnings can be ignored depending on the situation at that time, even though they are also helpful to keep the code quality.
Since we just cannot afford to manage them, we are always welcome to fix them!
Here is the detailed discussion if you want to see it.
Looking for something to work on?
If you are new contributor to Zellij
going through
beginners should be a good start or you can join our public
Discord server, we would be happy to help finding
something interesting to work on and guide through.
Tips for Code Contributions
Prefer returning Result
s instead of unwrap
ing
- Add
use zellij_utils::errors::prelude::*;
to the file - Make the function return
Result<T>
, with an appropriateT
(Use()
if there's nothing to return) - Append
.context()
to anyResult
you get with a sensible error description (see the docs) - Generate ad-hoc errors with
anyhow!(<SOME MESSAGE>)
- Further reading: See here
Logging errors
- When there's a
Result
type around, use.non_fatal()
on that instead oflog::error!
- When there's a
Err
type around, useErr::<(), _>(err).non_fatal()
- Also attach context before logging!
- Further reading: See here
Adding Concrete Errors, Handling Specific Errors
- Add a new variant to
zellij_utils::errors::ZellijError
, if needed - Use
anyhow::Error::downcast_ref::<ZellijError>()
to recover underlying errors - Further reading: See here
Filing Issues
Bugs and enhancement suggestions are tracked as GitHub issues.
Lacking API for plugin in Zellij?
If you have a plugin idea, but Zellij still doesn't have API required to make the plugin consider opening an issue and describing your requirements.
How Do I Submit A (Good) Bug Report?
After you've determined which repository your bug is related to and that the issue is still present in the latest version of the master branch, create an issue on that repository and provide the following information:
- Use a clear and descriptive title for the issue to identify the problem.
- Explain which behavior you expected to see instead and why.
- Describe the exact steps to reproduce the problem in as many details as necessary.
- When providing code samples, please use code blocks.
How Do I Submit A (Good) Enhancement Suggestion?
Instructions are similar to those for bug reports. Please provide the following information:
- Use a clear and descriptive title for the issue to identify the suggestion.
- Provide a description of the suggested enhancement in as many details as necessary.
- When providing code samples, please use code blocks.
Submitting Pull Requests
Instructions are similar to those for bug reports. Please provide the following information:
- If this is not a trivial fix, consider creating an issue to discuss first and later link to it from the PR.
- Use a clear and descriptive title for the pull request.
- Follow Conventional Commit specification where sufficiently large or impactful change is made.
- Provide a description of the changes in as many details as necessary.
Before submitting your pull request, also make sure that the following conditions are met:
- Your new code adheres to the code style through running
cargo fmt
. - Your new code passes all existing and new tests through running
cargo test
.