How does this differ from jekyll-commonmark?

[0xdevalias]

(Similar question posted at jekyll/jekyll-commonmark#39)

I notice that while the readme for jekyll-commonmark talks about using libcmark, it actually appears to achieve this via the commonmarker gem.

Looking at commonmarker, it talks about being a ruby wrapper for libcmark-gfm, which apparently includes all of the GFM extensions already:

Ruby wrapper for libcmark-gfm, GitHub's fork of the reference parser for CommonMark. It passes all of the C tests, and is therefore spec-complete. It also includes extensions to the CommonMark spec as documented in the GitHub Flavored Markdown spec, such as support for tables, strikethroughs, and autolinking.

This would make me think that jekyll-commonmark by itself already supports GFM, and so i'm wondering what jekyll-commonmark-ghpages provides above/beyond that, particularly as this project also uses the same commonmarker gem.

--

Adding jekyll-commonmark to my Gemfile resulted in the following in my Gemfile.lock:

jekyll-commonmark (1.3.1)
      commonmarker (~> 0.14)
      jekyll (>= 3.7, < 5.0)

commonmarker (0.21.0)
      ruby-enum (~> 0.5)

Resetting, then adding jekyll-commonmark-ghpages to my Gemfile resulted in the following in my Gemfile.lock:

jekyll-commonmark-ghpages (0.1.6)
      commonmarker (~> 0.17.6)
      jekyll-commonmark (~> 1.2)
      rouge (>= 2.0, < 4.0)

jekyll-commonmark (1.3.1)
      commonmarker (~> 0.14)
      jekyll (>= 3.7, < 5.0)

commonmarker (0.17.13)
      ruby-enum (~> 0.5)

So jekyll-commonmark-ghpages gives us an additional version dependency on rouge, but we already get that via jekyll anyway:

jekyll (4.1.1)
      ..snip..
      rouge (~> 3.0)

By the looks of this, by using jekyll-commonmark instead of jekyll-commonmark-ghpages I would actually be getting a more up to date version of commonmarker (and thus the underlying c implementation), that supports GFM. Which to me, at face value, is definitely not what I would have expected.

I can see that there is a semi-related issue / PR (#13 , #15) talking about loosening the version lock on the commonmarker dependency, which would allow it to get the same newer version as jekyll-commonmark currently is able to. I also noticed #11 that talks about documenting the fact that commonmarker is used under the hood, rather than a direct dependency on libcmark-gfm as this project's readme implies.

[0xdevalias]

I also noticed github/pages-gem#699 which states that the pages-gem (which claims to version gem dependencies used by ghpages; updated in 2020, so seems active) appears to be using the default Kramdown parser, instead of this project, which casts further doubt in my mind as to what the 'correct' choice is.

[0xdevalias]

For anyone else wondering, @pathawks provided an answer at jekyll/jekyll-commonmark#39 (comment), quoted here:

It is my understanding that the commonmarker Gem that we require is merely an FFI wrapper around libcmark. If that is no longer the case, we can certainly update this project or at least update the Readme.

To answer your broader question: if I remember correctly, we both started at around the same time. My intent when starting this project was (primarily) to utilize the fastest Markdown processor available in Ruby and (secondarily) conform to the then emerging CommonMark spec. I imagine the GitHub Pages team is more focused on building a processor that behaves similar to the GitHub Flavored Markdown processor used on the site. The fact that we are both using the same tech under the hood is kind of an implementation detail. 🤷🏼‍♂️