githubmarkdowngithub-flavored-markdowncommonmark

What library does Github use for parsing markdown?

Github "uses" github flavored markdown but I haven't been able to find what that means exactly. What parsing library do they use on the client to render the preview(s)?

Is the same lib used for *.md files, issues, and wiki pages?

Bonus points if you can point me to a resource that shows how github flavored markdown and commonmark overlap and how they are different.

Solution

  • point me to a resource that shows how github flavored markdown and commonmark overlap and how they are different.

    This is now (March 2017) officially documented: see "A formal spec for GitHub Flavored Markdown"

    Starting today, all Markdown user content hosted in our website, including user comments, wikis, and .md files in repositories will be parsed and rendered following a formal specification for GitHub Flavored Markdown.

    This is detailed in "A formal spec for GitHub Flavored Markdown"

    This formal specification is based on CommonMark, an ambitious project to formally specify the Markdown syntax used by many websites on the internet in a way that reflects its real world usage.
    CommonMark allows people to continue using Markdown the same way they always have, while offering developers a comprehensive specification and reference implementations to interoperate and display Markdown in a consistent way between platforms.

    The idea is:

    Taking the CommonMark spec and re-engineering our current user content stack around it is not a trivial endeavour.
    The main issue we struggled with is that the spec (and hence its reference implementations) focuses strictly on the common subset of Markdown that is supported by the original Perl implementation.
    This does not include some of the extended features that have been always available on GitHub. Most notably, support for tables, strikethrough, autolinks and task lists are missing.

    In order to fully specify the version of Markdown we use at GitHub (known as GFM), we had to formally define the syntax and semantics of these features, something which we had never done before. We did this on top of the existing CommonMark spec, taking special care to ensure that our extensions are a strict and optional superset of the original specification.