Open 0xdevalias opened 4 years ago
I also noticed https://github.com/github/pages-gem/issues/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.
For anyone else wondering, @pathawks provided an answer at https://github.com/jekyll/jekyll-commonmark/issues/39#issuecomment-662161067, 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. 🤷🏼♂️
(Similar question posted at https://github.com/jekyll/jekyll-commonmark/issues/39)
I notice that while the readme for
jekyll-commonmark
talks about usinglibcmark
, it actually appears to achieve this via thecommonmarker
gem.Looking at
commonmarker
, it talks about being a ruby wrapper forlibcmark-gfm
, which apparently includes all of the GFM extensions already:This would make me think that
jekyll-commonmark
by itself already supports GFM, and so i'm wondering whatjekyll-commonmark-ghpages
provides above/beyond that, particularly as this project also uses the samecommonmarker
gem.--
Adding
jekyll-commonmark
to my Gemfile resulted in the following in myGemfile.lock
:Resetting, then adding
jekyll-commonmark-ghpages
to myGemfile
resulted in the following in myGemfile.lock
:So
jekyll-commonmark-ghpages
gives us an additional version dependency onrouge
, but we already get that viajekyll
anyway:By the looks of this, by using
jekyll-commonmark
instead ofjekyll-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 (https://github.com/github/jekyll-commonmark-ghpages/issues/13 , https://github.com/github/jekyll-commonmark-ghpages/pull/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 https://github.com/github/jekyll-commonmark-ghpages/issues/11 that talks about documenting the fact thatcommonmarker
is used under the hood, rather than a direct dependency onlibcmark-gfm
as this project's readme implies.