Development guide
Kittynode is open to everyone, and happily welcomes any contributions!
Working with the codebase
Get started with the codebase and running development commands.
Prerequisites
Development commands
-
Clone the repo and change into the directory:
-
Install dependencies:
-
Install Rust dev tools:
-
See the full list of commands:
Managing releases
We push a tag <package-name>-0.y.z-alpha
to GitHub, and CI will build and publish a draft release for the package. We auto-generate a changelog with GitHub, and publish a latest release (this gives us links to refer to the latest release).
You can find all the latest releases here.
We will support package-level changelogs and semantic versioning in the future, but during the rapid development phase we don’t want to waste time on that.
Coding principles
Testing philosophy
Here are the tests we (currently) employ in the project:
- Unit tests for kittynode-core
- Behavior tests for kittynode-cli
Inside of unit tests we discourage mocking. For example, you could mock out the filesystem and networking like Docker (things on the host OS), but this leaks the integration boundary into the data transformation logic in the unit tests. A unit test is basically just taking in some primitive data, transforming it, and getting something out. This is what we strive to capture in the unit tests, and leave the interface boundaries for higher level tests (like behavior tests).
We also remain generally aligned with the testing pyramid (we want lots of cheap unit tests, with less expensive integration tests). This should form a “wide bug catching filter” (if you view it as an inverted pyramid).
Additionally, we don’t strive for 100% code coverage. That’s not the goal of writing tests in this project. We try to colocate our tests to explain how the codebase works for developers, but also ensure that our function behaves in the way we expect it to.
Code coverage
We include coverage from the integration tests in our total code coverage. This means code coverage is a holistic quality check for the codebase that represents an aggregate of our testing strategies and the code paths we are hitting in our test suite.
It would be useful to have a sense of what percentage of code paths are hit by unit tests versus integration tests, but we don’t do that for now.
Logging
We like logs. In library functions it’s essential, in “binding” layers it’s highly encouraged (as the API is homogeneous and we should trace out the entry here), and in other layers it’s optional / as needed. In the other layers it’s best to use your judgement but not litter with too many logs.
In consumers of library functions we (optionally) log at the entrypoint. Inside the library functions we log after the success / failure of the operation. We also always write our logs in sentence case without a trailing period.
In JavaScript we should at minimum log errors when calling library functions or external APIs at all (in a try-catch), and other logging is (currently) just best judgement.
The log functions we use are:
- Rust:
info!()
anderror!()
- JavaScript:
console.info()
and customerror()
Troubleshooting
Deploying to iOS
Some notes until we get it resolved upstream in Tauri:
- Make sure the physical device is properly connected and xcode is open.
- Make sure any last build is uninstalled from the device.
- See the justfile for more clean up commands.
- If you don’t see the iOS IP, then it’s a connection issue.
Other
You can also try some of these commands which used to be in the justfile
:
© 2025 Kittynode contributors – MIT License