Markdown Processor Choice in Jekyll 4.0: Enabling GitHub Flavored Markdown via jekyll-commonmark

Developers aiming for a repeatable Jekyll workflow often want local builds to render exactly as GitHub Pages does, which uses GitHub Flavored Markdown. Jekyll 4.0 continues to ship kramdown as the default markdown processor, while GFM support is only available through the optional jekyll‑commonmark gem. Adding this gem requires editing the Gemfile, setting markdown: CommonMark in _config.yml, and restarting the server, and there is no official guarantee that future Jekyll releases will keep the gem compatible.

The uncertainty lies in whether relying on a third‑party processor introduces drift between local and production environments, especially for sites that already contain kramdown‑specific syntax such as footnotes or table formats. Switching processors after content creation can cause rendering breaks, yet staying with kramdown may produce previews that differ from GitHub’s.

What are the risks of adopting jekyll‑commonmark as the default markdown processor for new Jekyll sites? How does enabling GFM via jekyll‑commonmark affect existing kramdown‑based content? Should the Jekyll project provide an official, built‑in GFM mode to guarantee repeatable builds that match GitHub Pages?