Because we needed easy way to modify syntax & output. Almost all parsers i know have hardcoded logic.
Because i wished to improve my skills in writing high-speed js, and this project was good for it.
Key differences with reference parcer
Focused on producing safe HTML out of box in one step. Instead of universal data abstraction layer.
Token steam instead of AST. More simple (IMHO), and enougth to support local transformation filters.
It’s still technically possible to convert data into commonmark ast, but no reasons to do it in core.
HTML disabled by default. Any features can be added via plugins in secure way.
We can’t run owasp validator in browser, it’s more simple to disable html at all.
But it’s not a big problem. In 99% people use HTML because it’s hard to modify parser. markdown-it has no such problems. You will be able to do everything without html, in secure way.
SourceMapping limited to line numbers only (no time, not needed now for our tasks).
High speed (it’s actually faster than all available JS parsers for markdown).
Very easy to modify. Everything!
With default settings parser is more close to GH’s, and tends to support the most demamded features, not yet covered in CM spec. But it still has strict CM mode, and existing syntax is periodically syncronized with CM on spec updates.
This parser is not better or worse than reference one. It have different goals, different priorities, different architecture and so on. We have no primary goal to promote new standard, but we like to follow CM spec.
PS. Of cause, tons of thanks to @jgm for his outstanding efforts on writing CommonMark spec.
This release contains some incompatible internals changes, but this should be not noticeable at top level, if you did not used full preset. If you used full - just drop it and load ‘missed’ features via use().
Due renderer refactoring, speed regression is ~20% in node v.10, and up to 50% in node v0.12 and iojs v1.5.0. Note, that some speed loss caused by v8 in new node versions. There are things, which can be done faster, but, honestly, i don’t wish to spend many time for it, because total speed is good enougth.
As you can see in tracker, we solved all issues, except some minor related to current spec state. We have done everything we needed, and have to continue with other projects. Of cause, we will support future spec conformance and bugfixes.
Do you maintain a list of high profile projects that use markdown-it? I noticed that the pretty trendy ProseMirror project was using it. Now I’m curious to know what other projects might be using your library.
Edit: I guess the list of dependents on npmjs.com has some decent coverage:
Version bump caused by some incompatible internals change (can break external plugins). Public API left intact. See migration info for details.
If you are plugin author and have trouble with updating your plugin - create issue in tracker with details, me & alex will try to help. Also see the list of our updated plugins and src changes.
Just for info: markdown-it is now 8.0.0 and follows CM 0.26 spec. It’s stable and forks fine with current features.
Next major improvements could be sourcemap support, but that requires:
AST design
major rewrite (token stream to AST, plugins, AST api)
more stable CM spec (desired), because it can affect some algorythms very much
We have no plans to do it in nearest future, because that requires a lot of time. But if anyone is interested, we could collaborate efforts to “split costs”. Feel free to contact me, if you have some ideas about.