Bacon for everything - a roadmap

You want to use bacon on non rust projects ? So do I.

Bacon watches sources, executes cargo tasks (compile, lint, test, etc.), then, on end, anlyzes 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 it turns out that other language ecosystems lack such tool.

For 5 years, the obvious opportunity wasn't discussed because we were few programmers using bacon, and I had no intention of doing anything else than rust anymore.

Then bacon started to be known, and I had a look back at some old non rust projects.

It's time to unleash bacon and I'll try here to define the plan.

Support launch without bacon.toml file

The bacon.toml file is useful to find the enclosing workspace, or the external source directories (eg on dependences given by a path).

But it should be possible to launch bacon when no such file exists.

That's the first step and what this Pull Request should make possible.

Progress:

• PR #256 merged, next bacon release will thus support launching without bacon.toml

New analyzers

An analyzer labels the lines that a tool ran by bacon returns on stdout and stderr, then builds a report with all the errors, warning, test failures.

The concept of selecting an analyzer for a bacon job appeared in bacon 3. Its first goal was to support nextest, which, while integrated in cargo, had a different output structure.

I'm currently using an analyzer I made for eslint. It should soon find its way into the main branch.

Here's the matching bacon.toml file:

default_job = "eslint-server"

[jobs.eslint-server]
command = ["npx", "eslint", "--color", "libs/*"]
need_stdout = true
analyzer = "eslint"
watch = ["libs"]

What would be needed now is developpers either asking for other analyzers or contributing some.

The analyzer's first task is to recognize what a line means (is it the location of something ? Is it the information that a test failed ? etc.).

To convey information to the user, dev tools style their output, using ANSI escape sequences (i.e. some bytes inserted to make text bold, or red, etc.). This styled output is thus what bacon recognizes.

A line received by the analyzer is defined by an origin (STDOUT or STDERR) and a sequence of styled strings.

To ease writing or fixing analyzers, I've added an "analysis export" function in bacon, which you call with ctrle.

Writing an analyzer should usually start with moving the bacon-analysis.json file to the /tests/line_analysis and modifying the "analysis" entries in this file so that they become test expectations.

Progress:

• eslint analyzer merged, will be available in next bacon release
• python_unittest analyzer in tests: PR #260

Improve the analyzer framework

Writing an analyzer is still rough.

There's code duplication, non obvious things to do, and I expect some tools' outputs won't be as easy to analyze as the ones I added support for already.

The LineAnalysis struct and the LineType enum were designed for cargo outputs, they need to be modified. Most notable, a line should be able to have more faces, eg contain both the title of a test failure and the line and column in the file (but not the file path).

This effort runs in parallel with the addition of new analyzers as their implementation and the problems encountered will help define the needs.

Introduce BURP

Rather than having bacon decypher the output of the program it calls, the symmetric approach would be to have the called program write an output that bacon can understand.

This implies a normalization. Let's call it BURP: Bacon Unified Report Protocol.

This protocol must describe how to have, in a STDOUT or STDERR stream, items which

• would have a kind among error, warning, test failure, test success, maybe other ones (benchs?),
• whould have a summary
• would have one or several locations (path to the file, line, column)
• could have a type
• could have some details in text (explanation, solution, etc.)
• could have its own STDOUT and STDERR (think tests)

The first draft of BURP would be "Do it as Cargo does, with the same ANSI escape sequences.".

Almost immediately would come the need to add some capabilities or alternate ways to produce the information. Hopefully it would still be a superset of what Cargo does.

If people serioulsy want to adapt some tools for bacon, or to write some adapters, we'll have to write a more detailed specification, of course.

BURP transformers

Waiting for all tools to be adapted won't be a reasonnable option.

A complementary approach is to write programs transforming the output streams of a command into a BURP compliant stream or pair of streams.

The good cases will be when we don't have to wait for the end of the command execution and we can keep items flowing as they're discovered by the tool. This probably won't always be possible.

Support transformers in Bacon

Good and reliable transformers for widely used tools should be directly integrated in bacon so that we can simply define jobs with a transformer=something parameter.

This of course implies that those transformers be written in Rust.

And it makes it obvious that a crate dedicated to producing BURP compliant lines will be useful. The good news is that it's trivial to write.

Configuration based generic BURP transformers

If we make BURP generic enough, there's a whole class of tools for which a transformer could be defined with simple pattern based line by line transformations.

So we could have a generic transformer defined simply with a configuration file.

If the approach reveals powerful and generic enough, this configuration could even be included in the bacon.toml file.

Job Sequences

The cargo world is quite exceptionnal in its simplicity. Most Rust projects are built with just a cargo build.

Extending to other ecosystems will increase the already identified need.

I'll be cautious here, I don't want bacon to become another Makefile like tool, as none of them can be general enough to support all needs. I'd rather encourage having the output of those tools being consumed by bacon.

But some minimal features appear necessary, at least chaining commands.

Be involved

Some work is necessary and this blog post isn't even a proper roadmap yet.

I'm working on this when I can but if I'm alone, a "bacon ecosystem" will be limited to what I need. At the very least I need people to tell what they'd need.

If you want to help bacon land on more languages and more tools, if you want to improve this roadmap or work on the implementation, please come to the chat.