Adopt commonmarker for markdown parsing #104
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Replaces markly with commonmarker Markly is a key piece in the original implementation of the ERB-enhanced markdown rendering in Joy of Rails—adapted from phlex-markdown and built on phlex-ruby. * https://github.com/ioquatix/markly * https://github.com/joeldrapper/phlex-markdown According to the markly README, it was originally created as a fork of commonmarker to get access to the parsed markdown Abstract Syntax Tree (AST). The fork is from before commonmarker switched from being a wrapper of cmark-gfm (implemented in C, gfm = GitHub-flavored markdown) to comrak (Rust port of cmark-gfm), also maintained by awesome maintainers. * https://github.com/github/cmark-gfm * https://github.com/kivikakk/comrak It's been nearly a year since markly was released. Just a few days ago, commonmarker introduced access to its AST meaning it supplies the key feature set to make it compatible for markdown rendering enhancements in Joy of rails. I checked it out this morning and reported an issue with code fence parsing early today that has already been fixed as of this afternoon—a Saturday no less—in commonmarker v1.1.2. * Issue: gjtorikian/commonmarker#289 * Fix: gjtorikian/commonmarker#290 * Release: https://github.com/gjtorikian/commonmarker/releases/tag/v1.1.2 Performance benchmarks are reported on commonmarker's README. According to these benchmarks, commonmarker outperforms Kramdown by over 25x. markly outperforms commonmarker by roughly 3x. * https://github.com/gjtorikian/commonmarker?tab=readme-ov-file#benchmarks That said, this changeset provides the minimum changes to switch from markly to commonmarker for markdown parsing. Why change? The libs have similar functionality with regards to what Joy of Rails needs at this time. It feels like with commonmarker it is a little easier for me to figure out how to customize the configuration options. Markly's performance outshines commonmarker but not so much for me to say the tradeoff is painful. The energy in the commonmarker and comrak projects is encouraging. I also believe in markly's maintainer, who is awesome, and a terrific advocate for improvements in the Ruby ecosystem. Ultimately, my choice to switch is more about my perception of the momentum of the respective projects. I have no issues with reconsidering this decision at a later time assuming switching back is comparably straightforward.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Replaces markly with commonmarker
Markly is a key piece in the original implementation of the ERB-enhanced markdown rendering in Joy of Rails—adapted from phlex-markdown and built on phlex-ruby.
According to the markly README, it was originally created as a fork of commonmarker to get access to the parsed markdown Abstract Syntax Tree (AST). The fork is from before commonmarker switched from being a wrapper of cmark-gfm (implemented in C, gfm = GitHub-flavored markdown) to comrak (Rust port of cmark-gfm), also maintained by awesome maintainers.
It's been nearly a year since markly was released. Just a few days ago, commonmarker introduced access to its AST meaning it supplies the key feature set to make it compatible for markdown rendering enhancements in Joy of rails.
I checked it out this morning and reported an issue with code fence parsing early today that has already been fixed as of this afternoon—a Saturday no less—in commonmarker v1.1.2.
Performance benchmarks are reported on commonmarker's README. According to these benchmarks, commonmarker outperforms Kramdown by over 25x. markly outperforms commonmarker by roughly 3x.
That said, this changeset provides the minimum changes to switch from markly to commonmarker for markdown parsing.
Why change? The libs have similar functionality with regards to what Joy of Rails needs at this time. It feels like with commonmarker it is a little easier for me to figure out how to customize the configuration options. Markly's performance outshines commonmarker but not so much for me to say the tradeoff is painful. The energy in the commonmarker and comrak projects is encouraging. I also believe in markly's maintainer, who is awesome, and a terrific advocate for improvements in the Ruby ecosystem.
Ultimately, my choice to switch is more about my perception of the momentum of the respective projects. I have no issues with reconsidering this decision at a later time assuming switching back is comparably straightforward.
Pull request checklist
bin/verify