Table of Contents
Can we use bacon on everything?
Bacon watches sources, executes cargo tasks on changes (compile, lint, test, etc.), analyzes the result, sorts it and displays it.
It's full of convenient features, like keeping the previous result available during computation of the next one, applying gitignore rules, sending problem locations to your IDE, paging and rewrapping on resize, switching task on key shortcuts, and more.
Bacon was initially developped for the Rust language.
As it turned out that other languages lacked such tool, it's progressively extended.
I previously wrote a roadmap, describing how I thought this could be done.
Now, this living document wants to be an overview of what's already available and what's in progress or planned.
Rust
There's no known gap, bacon can be used on everything Rust.
Rust specific support of bacon includes reading Cargo.toml files to identify all source directories, and help managing cargo features.
Cargo build, clippy, test, doc, run
Status: mature
These tools are quite different but produce warnings, errors, test failures, with the same representation.
Bacon doesn't even have to know which tool it is to analyze their output.
Support is complete. Any misinterpretation would be considered a bug.
Bacon also comes preconfigured for those tools, so that you can eg launch bacon test or switch to any of those jobs with just a key.
Miri
Status: mature
miri is supported with the default analyzer, and there's no known problem.
Bacon isn't preconfigured for miri but you can add a job with
[jobs.miri]
command = ["cargo", "+nightly", "miri", "run"]
need_stdout = true
Nextest
Status: mature
nextest is plainly supported and there's no known problem.
It doesn't use the standard analyzer but bacon comes preconfigured with a nextest job so that you can launch bacon nextest or simply hit n while in bacon.
Python
Support of Python is just starting, and Python developpers should raise their hand if they want to see progress here.
Unittest
Status: young
Support for the Unittest framework seems to work, but lacks testers and users.
Exemple configuration:
[jobs.unittest]
command = [
"python3", "unitest_runner.py",
]
need_stdout = true
analyzer = "python_unittest"
watch = ["."]
Pytest
Status: young
It's configured with
[jobs.pytest]
command = [
"pytest"
]
need_stdout = true
analyzer = "python_pytest"
watch = ["."]
Ruff
Status: young
Exemple configuration:
[jobs.ruff]
env.FORCE_COLOR = "1"
command = [
"ruff", "check",
]
need_stdout = true
analyzer = "python_ruff"
watch = ["."]
JavaScript / TypeScript
Eslint
Status: young
You need to specify the eslint analyzer:
[jobs.lint]
command = ["npx", "eslint", "--color", "libs/*"]
need_stdout = true
analyzer = "eslint"
watch = ["libs"]
Biome
Status: young
Biome (also works on CSS)
Example configuration (for a ./libs folder):
[jobs.biome-libs]
env.RAYON_NUM_THREADS = "1" # for constant ordering of items
command = [
"npx", "@biomejs/biome", "lint",
"--colors", "force",
"./libs",
"--skip", "complexity/useArrowFunction",
"--skip", "style/useTemplate",
]
need_stdout = true
analyzer = "biome"
watch = ["libs"]
C++
GCC / Clang
Status: young
Example configuration:
[jobs.gcc]
command = [
"g++", "-Wall", "src/main.cpp",
]
watch = ["src"]
need_stdout = true
analyzer = "cpp"
Other tools
What's not here, you should probably ask for it, either on GitHub or on the Miaou chat.
The most essential part, when dealing with a non cargo tool, is to decipher the output so as to recognize errors, warnings, failure tests, what text is the details of what problem, what are the locations (path to the file, line, column).
If you want to try your hands at working on it yourself, please contact me too for easier coordination.
To support another language or tool, three solutions are possible:
Implement an analyzer directly in bacon
This involves knowing (or learning) Rust, and the analyzer framework in bacon.
Messing with the code of bacon, while other tasks are in progress, may be a little painful too.
Write a converter to BURP
Bacons's Unified Reporting Protocol is the name of a not yet specified superset of how cargo outputs warnings, errors and test failures.
Changing a tool so that its output looks like cargo's one automatically makes it compatible with bacon.
But it's obviously not easy to add a feature to another tool, especially when their maintainers, not being rust programmers, don't know bacon.
Modify the other tool to output BURP
A converter transforming the output of a tool so that it looks like cargo can be either a good solution or a temporary POC before either an implementation in bacon or a modification of the tool.