Can warnings be promoted to errors?
Question
I made a change to my book.toml and typo'ed the command section of a preprocessor I was adding resulting in the command not being found. I assumed this would lead to an error but it didn't. Is it possible to promote these (and any) warnings to an error?
Thanks!
Version
0.4.42
@ehuss friendly ping on this question 😅
Could you provide an example that will generate a warning now and that you'd like to make it an error?
Providing [preprocessor.*.command] that points to a binary that doesn't exist
[preprocessor.mermaid]
command = "not-a-real-binary"
2025-03-06 05:29:06 [WARN] (mdbook::preprocess::cmd): The command wasn't found, is the "mermaid" preprocessor installed?
2025-03-06 05:29:06 [WARN] (mdbook::preprocess::cmd): Command: not-a-real-binary
I would consider this to have broken my docs but it's just a warining. I'd rather all warnings be treated as errors.
Oh, that's very different from what I thought.
As far as I understand this is considered only a warning in order to let mdbook work even if the given preprocessor is "not supported". For example if it is not installed.
The documentaion does not actually indicate if configured preprocessors are required or if they are optional, but right now they are optional.
Changing this might be considered as a breaking change, but I don't see why would we want to allow mdbook to run if one of the preprocessors is not available. In other words I am in favor of implementing the change suggested in this issue.
I think this would be a very nice change to make. The warnings are generally ignored and I only find out something is broken when an end user tells me about it. If a plugin is added to the book, it should be required to run successfully or be removed.
Hello
I have stumbled on this issue too. My coworker added support for Mermaid in our project configuration. The graphs weren't rendered on my machine as mdbook-mermaid wasn't installed. It took us a moment to see these lines in the log:
2025-03-14 14:44:40 [WARN] (mdbook::preprocess::cmd): The command wasn't found, is the "mermaid" preprocessor installed?
2025-03-14 14:44:40 [WARN] (mdbook::preprocess::cmd): Command: mdbook-mermaid
An option to promote warnings to errors would be appreciated too :)
Changing this might be considered as a breaking change, but I don't see why would we want to allow mdbook to run if one of the preprocessors is not available. In other words I am in favor of implementing the change suggested in this issue.
If it's just about changing the behavior to exit the application if a renderer is missing, I already have a patch that I can submit.
If it's just about changing the behavior to exit the application if a renderer is missing, I already have a patch that I can submit.
I know I would appreciate this patch!
Should I post the diff here or create a PR?
(It's really basic)
@Bktero create a PR and mention this issue
The PR is here https://github.com/rust-lang/mdBook/pull/2597
I found myself in a similar situation described by @freeform-andre and @Bktero. In my case, the {{#include ... }} path was broken, silently breaking my book. I wish my CI mdbook test step failed, avoiding the deployment of a broken book. Friendly ping to @ehuss and @szabgab.
I haven't tried but maybe this issue is now fixed by https://github.com/rust-lang/mdBook/pull/2797
Unfortunately, this is not covered by #2797. My warning is not related to a missing preprocessor but a broken {{# include ... }} path.