Note
I'd love feedback and testing on the formatter and linter, both help catch bugs and inconsistencies, but I'm just as interested in input on the formatting algorithm and lint rules, and what should be configurable. Please open an issue for any bugs or feature requests you run into.
cargo install --git https://github.com/bombsimon/monkey-c-rs rafikiTip
Since nothing here is stable yet, remember to pin your installation to avoid breaking changes.
cargo install --git https://github.com/bombsimon/monkey-c-rs rafiki --rev a1b2c3drafiki fmt # format the project
rafiki lint --fix # lint, applying what can be fixed
rafiki server # run the language server (for your editor)
rafiki coverage test -d <device> -y key # measure test coverageSettings can be pinned per project in a rafiki.toml, which the language server
reads too, so an editor and the command line always agree.
The command-line interface and single binary for all tools. The formatter,
linter, language server and coverage instrumentation are linked into it and
reached as rafiki fmt, rafiki lint, rafiki server and rafiki coverage.
A lexer, parser and AST for Monkey C.
A full representation of the Monkey C AST to support development of tools like formatters and linters.
A parser and printer for jungle files, the Connect IQ build language.
Parses a .jungle file into an AST that keeps its comments and blank lines, can
be edited, and writes itself back out.
The formatter behind rafiki fmt.
The main reason this project was created. An opinionated near-zero-config formatter that produces a deterministic formatting experience similar to ruff and rustfmt.
The linter behind rafiki lint, with machine-applicable fixes.
Rules walk the AST produced by monkey-c-parser and emit diagnostics with
optional --fix suggestions that patch source byte ranges directly. The
linter is independent of the formatter and fixes don't reformat unrelated code.
Run rafiki fmt after --fix if you want whitespace normalised.
The Language Server behind rafiki server.
Exposes the parser, linter, and formatter over LSP so any compatible editor gets live diagnostics (parse errors and lints) and document formatting. It speaks over stdio and keeps whole documents in memory (full sync).
Important
Garmin has their own LSP server bundled with the SDK that supports
definitions, declarations, references and other standard features. However
they do not have a formatter or linter so for now the plan for this project is
only to support the missing pieces. This LSP will therefore support
codeAction, formatting and diagnostics for code that isn't parsed
successfully.
Notes on the LSP server, its capabilities and how to run it from Neovim can be found in garmin-monkeyc.nvim. For the best developer experience it's suggested to run both servers together.
The rafiki.toml format, shared by the CLI and the language server so both
resolve a project's settings the same way.
The function-level test coverage instrumentation behind rafiki coverage.
Connect IQ has no native coverage support, so the source is instrumented before compilation: a probe after each function's opening brace records which functions the test suite actually executes, including those reached indirectly.
Warning
Coverage is function-level only, a fully executed 200-line function counts the same as a one-line one.
For transparency: this project is being built with assistance of AI. However, all implementations are suggested by me, discussed, and reviewed before being committed. The focus is still to build the best tools possible and know and understand 100% of the codebase. Although not every line of code is written by hand, the goal is to to avoid slop.
In addition to this project I'm also working on other projects to improve the developer experience for Garmin Connect IQ development.
- garmin-monkeyc.nvim - A Neovim port of the VS Code Connect IQ plugin
- tree-sitter-monkey-c - Tree-sitter implementation for Monkey C
- awesome-garmin - An awesome list of Garmin applications and tools for Garmin
This repository is licensed under the MIT License