Monogram: 1つの実行可能 grammar から parser と syntax highlighting を生成する

Syntax highlighting まわりでは、長く同じ問題が続いています。parser は parser、highlighter は highlighter と別々に育ち、後者はしばしば手書き regex と edge case 修正の積み重ねになります。

その結果、少し複雑な構文が出るだけで色付けが崩れます。言語仕様に近いのは parser 側なのに、editor で毎日目に入るのは highlighter 側だからです。

今日書いておきたい johnsoncodehk/monogram は、その構図をかなり正面からひっくり返そうとしている repository です。狙いは「もっと大きい TextMate grammar を書くこと」ではなく、grammar 自体を唯一の事実源にすることです。まず grammar を実行可能な parser として動かし、その同じ定義から TextMate、tree-sitter、Monarch などの highlighter を派生させます。

GitHub API と repository page の公開情報を 2026-06-21 時点で見ると、この project は 119 stars、3 forks、主要言語は TypeScript。作成日は 2026-05-27、公開上の最新更新日は 2026-06-21 です。なお現時点では、GitHub metadata に SPDX license は表示されておらず、releases page にも 公開 release はありません。

Project overview

項目	内容
Repository	johnsoncodehk/monogram
位置づけ	1つの grammar から parser と複数の syntax artifact を派生する
Stars	119
Forks	3
主要言語	TypeScript
作成日	2026-05-27
最終更新日	2026-06-21
License 状態	GitHub metadata に SPDX license 表示なし
Latest release	2026-06-21 時点で公開 release なし

いちばん面白いのは「先に grammar を証明する」順序にしていること

README の核はかなり明快です。

Write a language’s grammar once, as an executable definition.

つまり、先に highlighter を書いて parser に近づけるのではなく、まず grammar を本当に動く parser にし、その grammar から highlighter を作る、という順序です。

この順序になると、意味はかなり大きく変わります。

syntax highlighting を手書き regex の推測に依存しない;
先に parser が構文構造を決める;
highlighter は、すでに検証済みの構造に従って派生される。

TypeScript のように曖昧さの多い言語では、この違いはかなり大きいです。README にある typeof x < y の例のように、regex ベースの highlighter は < が generic なのか less-than なのかを推測しなければいけません。一方 parser は grammar に従って判断できます。

派生先が TextMate だけで終わっていない

Monogram が面白いのは、成果物を 1 つの editor format に閉じていない点です。

README では、同じ grammar から次のものを出せると説明しています。

lexer;
CST parser;
TextMate grammar;
VS Code language configuration;
CST node types;
tree-sitter grammar と highlights query;
Monarch tokenizer。

つまりこの project が解こうとしているのは、「ある editor の色付けがときどき壊れる」という小さな問題ではありません。構文に依存する複数の artifact を、1つの構造定義から揃えられるか という、もっと大きい設計の問題です。

ここがうまく機能すると、parser、editor highlighter、language config、tree-sitter 側の実装が別々に drift していくコストをかなり抑えられるはずです。

README の検証姿勢がかなり硬い

構文系の side project は「より正確」「より賢い」といった説明で終わりがちですが、Monogram README はもう少し踏み込んでいます。

現在の主な対象として挙げているのは次の 4 つです。

TypeScript;
JavaScript;
HTML;
YAML。

そのうえで TypeScript については、

100% valid-code coverage；
97.8% bidirectional vs tsc。

と書いています。

ここで大事なのは数字の大きさより、まず parser として照合し、それから highlighter の正しさを語る という順序です。

Highlighter を parser grammar の上に乗せたいなら、この順番はかなり筋が通っています。逆にここが曖昧だと、結局は「ちょっと賢い別実装の highlighter」に戻ってしまいます。

すでに実運用に触れ始めているのも強い

README の中で、Monogram-derived grammar を使っている project として

vuejs/language-tools

が明示されています。Vue の TextMate grammar と VS Code language configuration に使われている、という書き方です。

これはかなり重要です。良い発想の parser / grammar project はたくさんありますが、実際の editor ecosystem に artifact を供給するところまで進むものは多くありません。

Monogram は少なくとも「理論上生成できる」で止まらず、実際の toolchain に差し込む意図を持っています。2026-05-27 作成で stars もまだ控えめな repository だと考えると、かなり良い進み方です。

Node 24+ を要求しているのも思想が見える

Quick start はかなり短いです。

npm install
node src/cli.ts typescript.ts

README では Node 24+ が必要だと明記されていて、.ts をそのまま実行し、tsx や別 build step に頼らない形を取っています。

この選択からも、作者が grammar を「そのまま動く定義」として扱いたいことが見えます。周辺の build pipeline を重くするより、grammar から直接 artifact を引き出したいわけです。

こういう小さく鋭い language tool では、この軽さはかなり大事です。核となる考え方は面白いのに、使い始めるまでが重いと、それだけで試されなくなるからです。

なぜ今この project を追う価値があるのか

Monogram の本質的な面白さは、「highlighter を生成できる」こと自体よりも、source of truth を grammar に戻していることです。

言い換えると、こういう問いをかなり真面目に置いています。

もし parser がいちばん言語仕様に近い層なら、highlighter や language config や tree-sitter query も、その grammar から下ろしてよいのではないか。

この方向には少なくとも 3 つの価値があります。

grammar と highlighter の長期的な分岐を抑えやすい;
曖昧な構文を regex の推測ではなく parser の構造で処理できる;
複数 editor / toolchain 向け artifact を同じ言語定義に寄せられる。

もちろん、Monogram は README でも active research project と書かれている通り、まだ発展途上です。公開 release がなく、license metadata も未整備な点を見ると、「すぐに広く安全に採用できる完成品」とはまだ言いにくいです。

ただ、それでも今の段階で追う価値はあります。こういう project は、成熟してからよりも、設計思想がまだ強く見えている早い時期の方が学べることが多いからです。

まとめ

johnsoncodehk/monogram の面白さは、「新しい syntax tool が 1 つ増えた」ことではありません。grammar -> parser -> highlighter の流れを、もう一度きれいにつなぎ直そうとしていることです。

先に grammar を証明し、その結果から highlighter を派生させる。先に言語構造を決め、そのあとで色を付ける。この順序は遠回りに見えて、長期的にはずっと筋が良いです。Syntax tooling の source of truth を考え直したい人には、かなり面白い repository だと思います。