-
-
Notifications
You must be signed in to change notification settings - Fork 475
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Suggestion] Use a Commonmark parser for the rendering of readmes #989
Comments
Another idea: make another special case for the rendering for Gitlab, as they now have an endpoint to render markdown: https://gitlab.com/gitlab-org/gitlab-ce/issues/24124#note_131775879 |
Note that the go-to commonmark parser for PHP is https://commonmark.thephpleague.com/ |
FYI This 100% meets the GFM spec, meaning that what we render should be nearly identical. (The only difference is that Github's Markdown API has some extra post-processing in their HTML pipeline, to do things like render emoji) |
Currently, the rendering of readmes has 2 different paths:
cebe/markdown
for other packages (as we don't have pre-rendered readme for them)This suggestion is about replacing
cebe/markdown
for the second case.Nowadays, most non-github repositories on packagist are probably Gitlab ones. And Gitlab's markdown is based on CommonMark (with a few extensions of their similar to the Github ones, see https://docs.gitlab.com/ee/user/markdown.html). And Bitbucket also uses CommonMark (https://confluence.atlassian.com/bitbucketserver/markdown-syntax-guide-776639995.html).
So using a CommonMark parser would probably be better for compatibility of the rendering. But
cebe/markdown
is not such a parser.The text was updated successfully, but these errors were encountered: