JavaScript で Markdown のライブラリを選定したい...

<!--  


- [What is the correct and most efficient way to handle MDX as of today in Next.js?](https://www.reddit.com/r/nextjs/comments/18ulrhc/what_is_the_correct_and_most_efficient_way_to/)

- Content-Type
- これがそうだった
    - https://qiita.com/domodomodomo/items/6586b9794b3798f53ebb.md
- ヘッダ見せれば早いか...
    - https://chatgpt.com/c/d852297b-4e5c-42fd-91bf-1b3ee3a23011


> 基本 net/http 使えば全てのサーバ処理は書けるのだけど、僕は JSON 返してるのに content-type の付け忘れが比較的多くて、そういう意味で return c.JSON(data) みたいな呼び出しの小さいフレームワークを使う事で content-type の付け忘れが防げている。
https://x.com/mattn_jp/status/1791109645433716859

https://help.obsidian.md/Editing+and+formatting/Obsidian+Flavored+Markdown

file(index.html).output()
file("index.html").rename("hello.html")
vim(sample.text).open()

  * 依存関係は箇条書きのツリーにするか...
  * package.json を解析する ChatGPT のツールみたいなのほしい...
    * 入力
      * 上位側のライブラリのリスト
      * 下位側のライブラリリスト
    * 出力結果
      * 木構造

  -->


:::note alert
書きなぐりです... まだ書きかけです... リンクとかぐちゃぐちゃです...
:::

目次

2. Markdown パーサ
3. Markdown 方言
4. サービス, SSG が採用しているパーサ
5. ライブラリが採用しているパーサ
6. 独自記法を定義することについて
7. そのほか















## 1. Markdown パーサ



||パーサ|方言|
|:-:|:-:|:-|
|1|[unified](https://github.com/unifiedjs/unified)|CommonMark のみ（GFM の拡張プラグインがあります）|これ単体では動作せず、プラグインを組み合わせて使う。広く使われているが全体像を把握しにくく調べにくかった。|
|2|[marked](https://github.com/markedjs/marked)|CommonMark, GFM の全部を採用 [*](https://marked.js.org/#specifications)|-|
|3|[markdown-it](https://github.com/markdown-it/markdown-it)|CommonMark, GFM の一部を採用 [*](https://github.com/markdown-it/markdown-it?tab=readme-ov-file#syntax-extensions)|
|4|commonmark|CommonMark のみ [*](https://github.com/commonmark/commonmark.js)|
|5|remarkable|CommonMark, GFM の一部を採用 [*](https://github.com/jonschlinkert/remarkable?tab=readme-ov-file#syntax-extensions)|-|
|6|showdown|Original のみ[*](https://github.com/showdownjs/showdown)(based on the original works by John Gruber)|-|


<details><summary>補足: 方言の互換性について</summary>

* CommonMark
  * unified と commonmark は双方共に CommonMark を「仕様」として採用していますが、双方の「実装」に互換性があるのか、unified と commonmark が実際に全く同じように Markdown -> HTML に変換するのかは調べてはいません。 
* GFM
  * 「CommonMark の仕様は厳密だけど GFM の仕様は曖昧だよね」という記事を見かけました。GFM の「実装」には互換性がなさそうなことに留意してください。
  * [GitHub Flavored Markdown は何であって何でないか- Qiita](https://qiita.com/tk0miya/items/6b81e0e4563199037018)
* リンク
  * [markdown parser javascript list - Google 検索結果](https://www.google.com/search?q=markdown+parser+javascript+list)
</details>



---

**npm trends**

![Screenshot from 2024-03-22 22-01-26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/254825/213f4cfb-9afd-4626-55e7-9cb99d1fadd3.png)

https://npmtrends.com/commonmark-vs-markdown-it-vs-marked-vs-remarkable-vs-unified

<!--

  https://x.com/Ver1000000000/status/1236619859208765441

  -->




<details><summary>補足１: 比較 markdown と markdown-it と unified</summary>

* 個人の感想です...
  * unified, marked, markdown-it の３つがメジャーかなという感じがします。
* marked
  * 速度: 1 小さく変換速度が速い。markdown-it の２倍くらい速い。
  * 拡張: 3 反面、拡張性はそこまでで SSG や Qiita, Zenn といった大きなサービスでは採用されていない様子でした。
* markdown-it
  * 速度: 2
  * 拡張: 2 拡張性がある。
* unified
  * 速度: 3
  * 拡張: 1 拡張性がある。unified は mdx の仕様を策定しているからか markdown-it に比して React 系のライブラリ, SSG では広く採用されているように見えました。
* [Comparison Javascript Markdown Parsers](https://umemotoctrl.github.io/mdpjs/)
  * パーサがどう変換するか比較してくれます。
  * ページ右上に変換時間も表示されます。marked が一番早そうです。
  * unified がないのが残念...

---

* [lang:ja markdown-it marked - X 検索結果](https://twitter.com/search?q=lang%3Aja%20markdown-it%20marked&src=typed_query&f=live)
* 以下のポストで remark は unified に読み替えてください。後述します。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">とりあえずmarked, markdown-it, remarkの比較はできた<br>markedはシンプル、markdown-itはプラグイン多いけど妙に複雑、remarkはプラグイン多いしやりたいことが簡単ならシンプルに拡張できる</p>&mdash; 数の子 (@k42un0k0) <a href="https://twitter.com/k42un0k0/status/1408356002450206725?ref_src=twsrc%5Etfw">June 25, 2021</a></blockquote>

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">Markdownのちょっとした変換ツールを作りたいのでmarkdownライブラリを検討してる。<br><br>* marked 小さくてシンプルで見通しがいい。ただし、API的に親を参照して処理変えるのがきれいにはできない<br>* markdown-it: なんかドキュメントわかりづらい。親を参照するのはenv使えばできそう</p>&mdash; tai2 (@__tai2__) <a href="https://twitter.com/__tai2__/status/1700741130344919403?ref_src=twsrc%5Etfw">September 10, 2023</a></blockquote>

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">* remark: 抽象化されすぎて、処理複数リポに分割されててなんか見通し悪い。そこまで必要?心理的ハードル高い。visitのインターフェースは親参照できる形になってる。<br><br>けっきょく、ASTまでしか利用しない(AST -&gt; HTMLは自前)のであれば、どれ使っても大差ない。</p>&mdash; tai2 (@__tai2__) <a href="https://twitter.com/__tai2__/status/1700741131708088619?ref_src=twsrc%5Etfw">September 10, 2023</a></blockquote>

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">markedのParser.tsをコピペして改造する、が最適解かな。<a href="https://t.co/UY1OkwUvCp">https://t.co/UY1OkwUvCp</a></p>&mdash; tai2 (@__tai2__) <a href="https://twitter.com/__tai2__/status/1700787370386493884?ref_src=twsrc%5Etfw">September 10, 2023</a></blockquote>


* remark
  * 上記ポストで言及されている remark は unified のラッパのようなものだと思っています。unified はプラグインを組み合わせて Markdown -> HTML のパーサを組み立てます。remark は unified 本体とそのプラグインを予め組み合わせた便利セットみたいなものだと思っています。
  * > This package is a shortcut for unified().use(remarkParse).use(remarkStringify)
    > https://www.npmjs.com/package/remark#when-should-i-use-this

<!--

  https://github.com/remarkjs/remark?tab=readme-ov-file#when-should-i-use-this
  --> 

</details>







<details><summary>補足２: commonmark</summary>

* このパーサはあまり人気がないですが、メジャーな方言の１つである CommonMark の仕様が保存されているリポジトリにあったので記載しました。


</details>


<details><summary>補足３: unified</summary>

* グラフについて
  * unified の用途は Markdown から HTML に変換するだけではなく、ほかにも用途があるそうです（詳しくはわかっていません）。
  * そのため unified ではなく unified のプラグインで検索したほうがより正確な値かもしれません（例えば remark-parse）。
  * 本稿ではいろいろややこしいので unified で統一しています。
* unified の資料
  * unified のすごくわかりやすい資料です。これがなかったら一生 unified の全体像を把握できませんでした。ありがとうございます。
  * 関係は以下を参照、図があります。
    * [Next.js のための Remark / Rehype 入門 - Qiita](https://qiita.com/sankentou/items/f8eadb5722f3b39bbbf8)
  * 「unified のエコシステム」の節を参照
    * [Remark で広げる Markdown の世界](https://vivliostyle.github.io/vivliostyle_doc/ja/vivliostyle-user-group-vol2/spring-raining/index.html)
  * これはあまり読んでいません...
    * [unified を使って Markdown を拡張する - Zenn](https://zenn.dev/januswel/articles/745787422d425b01e0c1)

界隈のつよつよの人たちが unified に肯定的なコメントをしている... でも具体的に何を指しているのか、どうしてよいのかわからない...orz

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">Markdown 方言ガーって言ってる人いたけど、JSならunified/remarkで、ある程度はなんとかなるから、ポータビリティという点では、現状ではやっぱりMarkdownが強いと思うんだよなぁ</p>&mdash; erukiti (@erukiti) <a href="https://twitter.com/erukiti/status/1196593460389670912?ref_src=twsrc%5Etfw">November 19, 2019</a></blockquote>

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">テキスト処理のASTは結局 unifiedjs/unified として標準化されたなあ。 / “QiitaとMarkdownとコンテンツオーサリング - Qiita” <a href="https://t.co/J0PTyqBUPG">https://t.co/J0PTyqBUPG</a> <a href="https://twitter.com/hashtag/markdown?src=hash&amp;ref_src=twsrc%5Etfw">#markdown</a></p>&mdash; Aki＠めもおきば (@nekoruri) <a href="https://twitter.com/nekoruri/status/1220311082536857601?ref_src=twsrc%5Etfw">January 23, 2020</a></blockquote>

</details>






---

**GitHub Star History**

![Screenshot from 2024-03-22 20-33-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/254825/eb2fddb1-8c7f-916a-faf5-0ca691014b3a.png)

https://star-history.com/#unifiedjs/unified&markedjs/marked&markdown-it/markdown-it&jonschlinkert/remarkable&commonmark/commonmark.js&Date


<details><summary>補足１: unified について</summary>

* unified は GitHub Star History で検索すると npm trends に比べて極端に順位が落ちます。
* これは恐らく開発者が unified を直接ダウンロードしているのではなく、ほかのライブラリやフレームワークを経由して unified をダウンロードしているため、直接見ることがないからではないかと思っています。

</details>





<details><summary>補足２: 比較方法について</summary>

ちょうど Express vs NestJS でどうやって比較するのがいいのか？みたいなのが話題にあがっていました...

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">GitHub Star を付けるモチベが個々で違いすぎる(期待やブックマークだったり評価だったり)のと、Star 付けてない人の評価の方が実は多いと思ってます。なので実際まだ上回ってはないと思います。<br><br>例えば Google 検索結果<br><br>「js express」約 441,000,000 件<br>「js nestjs」約 4,610,000 件 <a href="https://t.co/H8eA0irxgK">https://t.co/H8eA0irxgK</a></p>&mdash; mattn (@mattn_jp) <a href="https://twitter.com/mattn_jp/status/1770955450827288990?ref_src=twsrc%5Etfw">March 21, 2024</a></blockquote>

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">指標としてはnpm のダウンロード数もありますね。それだとちょうど10倍差。 <a href="https://t.co/DEE54tnhsh">https://t.co/DEE54tnhsh</a></p>&mdash; 渋川よしき (@shibu_jp) <a href="https://twitter.com/shibu_jp/status/1770982282016477311?ref_src=twsrc%5Etfw">March 22, 2024</a></blockquote>

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">GithubのスターはTwitterのいいねくらいの信頼性だと思ってよさそう<br>星が多いなら無名ということはない、では頼れるライブラリかというとそれはまた別、じゃあGoogleトレンドのほうが信頼できるかだとまあGithub星のほうがマシ、でもGithubを見るくらいならNPMのダウンロード数のほうがマシ、みたいな</p>&mdash; Cubbit (@cubbit2) <a href="https://twitter.com/cubbit2/status/1771233097003970749?ref_src=twsrc%5Etfw">March 22, 2024</a></blockquote>

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

</details>








## 2. Markdown 方言



| # | 方言                | 説明                                        |
|---|---------------------|--------------------------------------------|
| 1 | [Original](https://bit.ly/3x5kUad) | Perl の実装、仕様。はじめて実装されたもの|
| 2 | [CommonMark](https://bit.ly/3Twd9l9) | 仕様。方言が乱立したため標準化しようとしたもの|
| 3 | [GFM](https://bit.ly/3TyzaQg) | 仕様。CommonMark を拡張したもの     |
| 4 | MaltiMarkdown                 | Perl の実装、仕様                  |
| 5 | PHP Markdown Extra            | PHP の実装、仕様                   |
| 6 | Pandoc                        | Haskell の実装、仕様               |






<details><summary>補足</summary>


* 個人の感想です。
  * Original, CommonMark, GitHub Flavored Markdown(GFM) の３つがメジャーかなという感じがします。
    * Original
      * 最初の方言です。その後さまざまな方言が乱立する。
    * CommonMark
      * という方言で標準化しようとする。
    * GitHub Flavored Markdown(GFM)
      * GitHub は CommonMark を拡張した GFM を使っている。という流れを抑えておくと良いかなと思いました。
* 方言の一覧はどこから引っ張ってきたの？
  *  RFC 7764 に記載されていました。
* 文書の性格
  * [RFC 7764](https://datatracker.ietf.org/doc/html/rfc7764#section-3)
    * 一覧
  * [RFC 7763](https://datatracker.ietf.org/doc/html/rfc7763)
    * text/markdown という content-type 作りましょうねと提案
    * 厳密な仕様ではなくあくまでも参考資料のようなもの
    * This document is not an Internet Standards Track specification; it is published for informational purposes.
* 方言
  * Original
    * `Markdown.pl`
    * RFC 7764 の一覧には Original の記載はありません。
    * Original の語の説明は RFC 7763 にあります。
    * 上記の表に Original があったほうが Original -> CommonMark -> GFM の流れがわかりやすいかなと思い追記しました。
    * Markdown の歴史、誕生 Original -> 乱立 -> 標準化 CommonMark の流れは英語版 Wikipedia に記述があります。
      * [Markdown - Wikipedia](https://en.wikipedia.org/wiki/Markdown)
  * GFM
    * 本稿では GitHub Flavored Markdown を GFM と略すことにします。
    * GFM は CommonMark を拡張した仕様です。
    * GFM が CommonMark から拡張した部分の仕様は、以下のリンクのうち緑のマーカで引かれた箇所になります。
      * [GitHub Flavored Markdown Spec](https://github.github.com/gfm/)
* 方言とパーサ（仕様と実装）
  * GFM や CommonMark のように純粋に仕様として定義された方言もありますが、それ以外 MaltiMarkdown, PHP Markdown Extra, Pandoc は実装を元にして定義された方言なのかなと思いました。

</details>













## 3. サービス, SSG が採用しているパーサ

||サービス|パーサ|補足|
|:-:|:-:|:-:|:-|
|1|Docsaurus|[mdx](https://bit.ly/3TOTHkR) -> [unified](https://bit.ly/3IPahuM)|React 製の SSG, 技術ドキュメント向け|
|2|Nextra|[unified](https://bit.ly/49aQW1K)|Next.js で使うライブラリ|
|3|Gatsby|[unified](https://bit.ly/4atVi5s)|React 製の SSG|
|4|VitePress|[markdown-it](https://bit.ly/3ToePNq)|Vue.js 製の SSG, 技術ドキュメント向け|
|5|Nuxt Content|[mdc](https://bit.ly/3vpHNol) -> [unified](https://bit.ly/3ISsJmi)|Nuxt で使うライブラリ|
|6|Astro|[unified](https://bit.ly/3VxojZv)|JavaScript 製 SSG|
|7|Sphinx|[markdown-it-py](https://bit.ly/3TyRyIY)|Python 製の SSG, 技術ドキュメント向け|
|8|MkDocs|[Markdown](https://bit.ly/499nzwI)|Python 製の SSG, 技術ドキュメント向け|
|9|Zenn|[markdown-it](https://bit.ly/3TRXuhD)|-|
|10|Qiita|[Qiita Marker](https://bit.ly/3TPw8Zk)|Ruby 製|
|11|WordPress|調べてない|PHP 製, CMS の巨人|



<details><summary>補足</summary>

* 一覧
  * SSG
    * ここに SSG の一覧があります。GitHub のスター順にならんでいます。
    * [A List of Static Site Generators for Jamstack Sites](https://jamstack.org/generators/)
  * CMS
    * 調べてない...
* SSG
  * JavaScript 
    * React
      * Nextra
      * Docsaurus
      * Gatsby
    * Vue
      * Nuxt Content
      * VitePress
        * unified に比べると SSG やサービスで採用されていないように見えました。VitePress で採用されていました。VitePress が markdown-it を採用した理由は恐らく速度と拡張性と思われる。実際に速度を測ったわけではないです...
    * Astro
  * Python
    * Sphinx
      * 初リリース: 2008/03/21[*](https://bit.ly/3PD0OL0)
      * Python の開発ドキュメントを作る際に使用される SSG
      * markdown-it-py
        * markdown-it の移植版らしいです。
        * > This is a Python port of markdown-it, and some of its associated plugins.
          > https://github.com/executablebooks/markdown-it-py
    * MkDocs
      * 初リリース: 2014/01/24[*](https://en.wikipedia.org/wiki/MkDocs)
      * Python の開発ドキュメントを作る際に使用される SSG
      * Markdown
        * Original の仕様に則っているそうです。
        * > This is a Python implementation of John Gruber's Markdown.
          > https://github.com/Python-Markdown/markdown
        * CommonMark が策定されたのは 2014/10/25 です。
      * Original に準拠したライブラリがあったのは驚き...
  * サービス
    * Qiita と Zenn
    * Qiita, Zenn はなぜサーバサイドで markdown -> html の変換を行っているのか？音速で返ってきてびびった...
    * Qiita の markdown をそのまま Zenn に貼り付けても全然互換性がない... 結局、移植性みたいなのってあんまり気にしてもしかたないのかな...
    * 方言とかいうよりも、ライブラリの選定が重要になってくるのではないのか...
    * Qiita Marker
      * GMF 方言


https://x.com/azu_re/status/1772645677782409445?s=20

</details>


<!--

  CMS は？WordPress は？

  unified が使われている印象？

  |[6](https://github.com/hashicorp/next-mdx-remote/blob/main/package.json#L15)|mdx-next-remote|mdx -> unified|Next.js で使うライブラリ|

  Vue.js を用いた開発の際のドキュメントを書く際に広く使われているはず。
  コントリビュータに Vue.js の生みの親である Evan You がいる。主に技術記事を書くために開発された。

  JavaScript 製, Zenn のバックエンドは Ruby on Rails と聞いていた。
  
  * Obsidian
  * [Nextra](https://zenn.dev/soata/articles/085fcf674a8978)
  * astro
    * https://github.com/withastro/astro/blob/main/packages/astro/package.json#L119

  [Astro](https://github.com/withastro/astro/blob/main/packages/astro/package.json#L119)
  https://github.com/withastro/astro/blob/main/packages/markdown/remark/package.json
  
  markdown-remark
  
https://github.com/withastro/astro/blob/297571eb98509a63f894d6fff912775b637a1482/packages/astro/src/vite-plugin-markdown/index.ts#L34

  https://x.com/dumblepytech1/status/1770261048526061727?s=20

  https://x.com/d151005/status/1663537590212108288

  -->












## 4. ライブラリが採用しているパーサ

* React
  * marked-react
    * [marked](https://github.com/sibiraj-s/marked-react/blob/8de26b9f020eb110cfaaa567e492126d97206f6a/package.json#L48) 
  * markdown-to-jsx
    * [markdown-it](https://github.com/quantizor/markdown-to-jsx/blob/90121795e872d01cb61e703716ff49e81851ec6a/package.json#L69)
  * react-markdown
    * [unified](https://github.com/remarkjs/react-markdown/blob/a27d335fc5419db4a2811e7f589d6467218346de/package.json#L86)
  * react-remark
    * [unified](https://github.com/remarkjs/react-remark/blob/5b21d53d98a5ad9496947ecba8c65aab8262223e/package.json#L43)
* React (Next.js に特化したもの) 
  * @next/mdx ... local の MDX ファイルが対象です, hot reload が効きます
    * @mdx-js/loader ... Webpack を使って bundle しています
      * @mdx-js/mdx
        * unified
  * next-mdx-remote ... remote のファイルが対象です, hot reload は効きません
    * [@mdx-js/mdx](https://github.com/hashicorp/next-mdx-remote/blob/bab00c7b8530ad2c3e34641c03f033376246b085/package.json#L15)
      * unified
  * 上記２つのライブラリは Next.js の公式ドキュメントに使用方法の記載があります。
    * [Configuring: MDX | Next.js](https://nextjs.org/docs/app/building-your-application/configuring/mdx)
  * mdx-bundler
    * [@mdx-js/esbuild](https://github.com/kentcdodds/mdx-bundler/blob/f13d978198561e6d29b48207a46613142894f864/package.json#L45)
      * [@mdx-js/mdx](https://github.com/mdx-js/mdx/blob/78aee48581241bd6d3cc6e0e7fad8cac5ef27c65/packages/esbuild/package.json#L41)
        * unified
* Vue.js
  * @nuxtjs/mdc ... Nuxt でなく Vue.js 単体でも使えます[*](https://github.com/nuxt-modules/mdc?tab=readme-ov-file#rendering-in-your-vue-project)
    * [unified](https://github.com/nuxt-modules/mdc/blob/42613d5b75882efcec9f2bc7fea1749be4d88ba9/package.json#L104)
* そのほか
  * Markdoc ... Stripe のドキュメント, 技術ドキュメントガチ勢が作ったライブラリ
    * [markdown-it](https://github.com/markdoc/markdoc/blob/f59adb5c5321a41a212b58dbfcd9f98236296719/package.json#L61)


---

![Screenshot from 2024-03-23 08-10-52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/254825/479b1aaf-8a67-9bb4-379d-0072e7125655.png)

https://npmtrends.com/markdown-to-jsx-vs-mdx-bundler-vs-react-markdown



---

![Screenshot from 2024-03-23 08-08-06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/254825/970dc31a-2efd-5ceb-aa26-8a0020037e74.png)

https://npmtrends.com/@next/mdx-vs-next-mdx-remote



---

<details><summary>補足１: なにを調べたの？</summary>

* 上記に前節「3. サービスが採用しているパーサ」で挙げたものより低レイヤのライブラリを列挙しました。SSG やサービスに結びついていないライブラリ。
* 3, 4 をまとめる方法が思いつかなかった。
* 各 JavaScript フレームワークで定義したコンポーネントを組み込める Markdown パーサで分類しました。
* 調べ方は package.json を掘り下げただけでソースコードをちゃんと読んで確認した訳ではありません。

</details>


<details><summary>補足２: 感想</summary>

* npm trends では unified, remarked, markdown-it が３強のパーサだが、知名度の高いサービスやライブラリは marked を使ってない？
* おそらく marked は小さい実装だから？拡張したりしないなら marked がいいのかな...
* Vue.js の公式ドキュメントの最初の方にあるサンプルコードで marked が使われているのは見たことがある...

</details>


<details><summary>補足３:</summary>

* next-mdx-remote と mdx-bundler の共通点
  * next-mdx-remote と mdx-bundler が存在する理由
    * > **getStaticProps は JSON に変換可能なやつしか渡せない** っぽいのでMDX のコンポーネントをどう渡すか迷ってたんだけど、next-mdx-remote 使うべきかなこれ使わないでできるなら使いたくないんだけど
      > https://twitter.com/d151005/status/1746103725209591877
  * package.json に unified があるので、どこかで unified を使っているはず...
  * でも `unified().use(rehypeParse)` のようなプラグインを組み合わせているコードが見当たらない
  * 別のアプローチを取っているように見える...
* next-mdx-remote と mdx-bundler の相違点
  * mdx-next-remote は mdx ファイル内で import はできない
    * https://x.com/remcohaszing/status/1619418379915501568
    * https://x.com/kentcdodds/status/1370492404818571265
* RSC を使えば getStaticProps を介さないから serialize したり code に変換しなくていいんじゃないのか？
  * next-mdx-remote には RSC 対応版が存在する... なにをしているんだろう？
    * [React Server Components (RSC) & Next.js app Directory Support](https://bit.ly/43yvSkT)
  * さらに next-mdx-remote のリポジトリでなにかを議論している...
    * https://github.com/hashicorp/next-mdx-remote/discussions/437
  * @mdx-js/mdx だけでもできる様子...(next-mdx-remote, mdx-bundler を使わなくても)
    * > This is similar to what people sometimes use mdx-bundler or next-mdx-remote for, but MDX also supports it
      > https://mdxjs.com/guides/mdx-on-demand/
* 比較記事
  * [MDX bundler with Next.JS](https://www.iamyadav.com/blogs/use-mdx-bundler-with-next-js)
  * [Comparison of MDX integration strategies with Next.js](https://dev.to/tylerlwsmith/quick-comparison-of-mdx-integration-strategies-with-next-js-1kcm)

<!--

* MDX の拡張について
  * [Markdown を拡張する MDX はドキュメント作成の新たな可能性？ - Zenn](https://zenn.dev/spring_raining/articles/3eb62ff93df1eb)
  * https://mdxjs.com/docs/extending-mdx/
* mdx-next-remote
  * [Zennの解説記事](https://zenn.dev/praha/articles/next-13-app-router-with-mdx)
  * https://x.com/Ningensei848/status/1724262854952362205

https://zenn.dev/hayato94087/articles/d358ab23947638
https://x.com/Hayao0819/status/1742245247504253389
https://x.com/buildsaascom/status/1751735677920710830
  -->

</details>
















## 5. 独自記法による拡張について

Zenn の生みの親である catnose さんは拡張記法を新たに定義することについては否定的なようです。

https://x.com/catnose99/status/1419434566897397760

https://x.com/catnose99/status/1419460691753246721

https://x.com/catnose99/status/1602279611341352960


↓ ガチ勢は Qiita ↔ Zenn の方言のパーサを実装してしまう... でも自分にはこんな能力はない...

https://zenn.dev/pullriku/articles/article-batch-management


↓ ちょっと面倒みたいな意見も見る...

https://x.com/ubugeeei/status/1774069508258562550
https://x.com/ubugeeei/status/1774070092625801280
https://x.com/ubugeeei/status/1774072621547798933




## 6. そのほか


---

**背景**

* どれが一番使われているパーサ、方言なのか知りたかった
* 諸般の事情で SSG としてではなく SSR で mdx-next-remote を使っていて、なんか実装が重く感じた。こんなにコネコネしないといけないのかな？みたいなかんじで。これで良いのか、これが一般的なのか疑問だった。Next.js 使うなら一般的だと思った。でもなんか重い...orz

---

**感想**

* 移植性を考えると Vue.js の template, React の JSX を使うよりも markdown の拡張記法を導入したほうがよい？
* 拡張したいなって思って Markdown のパーサを調べたけど、拡張しないほうがよいみたいな気もしてきた...
* 互換性がないから結局最初のライブラリの選定は大事なのかも...
* 変換速度とかどうなんだろう...
* commonmark.js で...
* marked は大御所では採用されていないが変換速度は速い
* 移植性みたいなことを考えると、いっそ独自の拡張記法は導入しない仕様のゆるふわな GFM も禁止して、 CommonMark + HTML タグだけってのもありなのではないのか...
* あるいは WYSIWYG のエディタを提供して HTML で保存するみたいな？でもそうすると WYSIWYG のエディタにロックインされるのかな？



<!--
  https://chat.openai.com/c/be65f6a5-a826-43f3-bc81-d188a3f93858
-->