Panache: Markdown、Quarto、R Markdown を 1 本の toolchain に戻す
開発チームの文書管理は、見た目よりずっと分裂しやすいです。
- 本文は Markdown;
- 一部は Quarto や R Markdown;
- 欲しいのは見た目の整形だけではなく diagnostics や code action;
- CI では
prettierやruffのように安定して回したい; - code block の中は別の language formatter に任せたい。
問題は、こうした要件が 1 つの tool にまとまっていないことです。
多くの Markdown tool は rendering か簡単な formatting には強い一方で、YAML frontmatter、citation、table、code block、Quarto 拡張構文まで含んだ文書工程になると途端に弱くなります。
今日メモしておきたい jolars/panache は、その空白をかなり正面から埋めに来ている project です。狙っているのは単なる formatter ではなく、language server、formatter、linter をまとめた文書向け toolchain です。対象も最初から Markdown、Quarto、R Markdown に向いています。
GitHub repository page、releases page、commits feed を 2026-06-24 時点で確認すると、この repository は 177 stars、9 forks、主要言語は Rust。repository の作成日は 2025-09-03、直近の公開 commit は 2026-06-24 です。license は MIT。最新 release は v2.58.0 で、公開日は 2026-06-23 です。
Project overview
| 項目 | 内容 |
|---|---|
| Repository | jolars/panache |
| 位置づけ | Markdown / Quarto / R Markdown 向けの language server、formatter、linter |
| Stars | 177 |
| Forks | 9 |
| 主要言語 | Rust |
| 作成日 | 2025-09-03 |
| 直近の公開 commit | 2026-06-24 |
| License | MIT |
| Latest release | v2.58.0 |
| Release date | 2026-06-23 |
| Project site | panache.bz |
単なる整形 tool ではなく、文書開発の流れ全体をそろえようとしている
README の説明はかなり明快です。Panache は language server、formatter、linter であり、対象は plain Markdown だけではなく：
- Markdown;
- Quarto;
- R Markdown;
です。
ここが大事です。技術文書の repository が大きくなると、文書はただの prose ではなくなります。
- frontmatter がある;
- citation や footnote がある;
- table がある;
- code block がある;
- analysis や notebook 的な要素がある;
- formatting と lint を分けて考える必要がある。
このとき tool が 1 項目しか面倒を見てくれないと、結局は editor、CLI、CI で別々の仕組みをつぎはぎすることになります。Panache はそこを 1 本にまとめようとしています。
LSP と CLI を同じ product として扱っているのが強い
README の design goals には、次のような項目があります。
- full LSP implementation;
- formatting と linting のための standalone CLI;
- Quarto、Pandoc、R Markdown syntax の support;
- lossless CST-based parsing;
- idempotent formatting;
- semi-opinionated だが調整可能な defaults;
- code block に対する external formatter / linter support。
これはかなり筋が良いです。
文書 tool でよくある問題は、editor 内の挙動と CI の挙動が別物になりやすいことです。ローカルで見える diagnostics と、commit 前に走る formatting と、CI の最終判定が別実装だと、使う側はすぐに疲れます。
Panache はそこを同じ core に寄せようとしています。editor 体験と automation を切り離さない設計です。
code block を外部 formatter / linter に渡せるのが実務的
この project でかなり重要なのは、文書を「ただの文字列」として扱っていないことです。
README では、code block に対して external formatter や linter を走らせられること、しかもよく使う language / tool 向け preset があることが明記されています。
これは技術文書ではとても自然です。現実の repository では、
- 本文は Markdown;
- code block は Python、R、JavaScript、Bash、YAML;
- block ごとに既存 ecosystem の formatter を使いたい;
- 文書 tool 自体が全部の language rule を再実装する必要はない;
という構成が普通だからです。
Panache はここで、すべてを内製するのではなく、文書レイヤーの orchestrator に近い立ち位置を選んでいます。これはかなり現実的です。
lossless CST と idempotent formatting を前面に出しているのも良い
README が強調している
- lossless CST-based parsing
- idempotent formatting
の 2 点も見逃しにくいです。
formatting tool が情報を落としたり、毎回少しずつ違う結果を出したりすると、チーム導入はかなり難しくなります。
- diff が汚れる;
- review が重くなる;
- pre-commit や CI に入れづらい;
- author が tool を信用しにくい;
からです。
Panache は少なくとも、demo が動けば終わりではなく、継続運用に耐える tool として設計しようとしているのが見えます。
配布経路が広いのも、toy project 以上の signal
README では install 方法もかなり揃っています。
- Homebrew;
- crates.io;
- pre-built binary;
- macOS / Linux installer script;
- Windows PowerShell installer script;
- AUR;
- NixOS;
- PyPI;
- npm。
これは地味に大きいです。
Rust tool が cargo install だけだと、Rust 開発者以外に広がりにくいことが多いです。でも文書工程では、platform engineer だけでなく、writer、analyst、researcher、教育用途の author も触る可能性があります。
Panache はそこをちゃんと意識しているように見えます。
向いている場面
公開情報を見る限り、Panache は次のような場面にかなり合っています。
- Markdown repository が大きくなり、整形以上の品質管理が必要になった;
- Quarto や R Markdown を含む文書を継続保守している;
- editor と CI を同じ rule で揃えたい;
- 文書にも code repository に近い quality gate を入れたい;
- code block 側では既存 formatter / linter を再利用したい。
技術ブログ、研究ノート、分析レポート、教材、knowledge base などは相性が良さそうです。
境界もはっきりしている
もちろん、Panache は万能ではありません。
見えている位置づけは、
- author / maintainer 向けの文書開発 tool;
- structured technical docs 向け;
- repository workflow 向け;
です。
なので、
- collaborative online editor がほしい;
- CMS や publishing backend が必要;
- 非技術ユーザー中心の visual writing を優先したい;
- hosting や editorial workflow までまとめて解きたい;
という用途にはそのままの答えにはなりません。
ただし、「技術文書 repository にも code repository 並みの language service と quality gate を入れたい」という課題には、とても正面から合っています。
なぜ追いかける価値があるのか
この project が面白いのは、Markdown の見た目を少し整える話に留まっていないからです。
Panache が埋めようとしているのは、
- editor 上の language service;
- CLI での formatting;
- CLI での lint;
- prose と code block の協調;
- local authoring と CI gate の一貫性;
という、文書工程でずっと不足しがちな部分です。
技術文書が長期保守対象になっている team ほど、この方向は効いてきます。
まとめ
jolars/panache は、Markdown を少しきれいにする tool ではなく、Markdown、Quarto、R Markdown をもっと現代的な開発対象として扱うための toolchain を作ろうとしている project です。
文書 repository がすでに構造化され、code block や quality gate まで含めて管理したくなっているなら、この repository はかなり見ておく価値があります。