What is the current scope of this project?

[kidonng]

Pin @hashrock since you have recently worked on this.

With #5 implemented and interests in #28, I think this project is going beyond the definition of "GitHub Flavored Markdown" (GFM), heading towards "Markup features supported by GitHub".

I'm not saying this is a bad thing, but we need to make things clear. This project, in its current form, is no longer just a GFM renderer (in which case, one would probably be better using micromark or remark). The description should be changed to something like "Server-side GitHub-style Markdown rendering for Deno".

And we need to draw the line somewhere. For example, the GitHub feature mentioned in #46 in too niche to have it here.

[hashrock]

Yeah good point...

I don't think it's possible to follow GitHub's rendering completely. I think GitHub is bringing complexity to README rendering these days, and I think it's a good idea to change descriptions to GitHub-style.

One reason we're sticking with GitHub-style rendering and not just gfm is this library has been used in deno.land/x, and the README.md(example) that is placed on GitHub needs to look the same in deno.land/x.

But we also use this for blogs and SSGs, and I don't think we can or should be fully compliant with GitHub. Maybe we need a plug-in mechanism to prevent the expansion of features and dependencies.

[kidonng]

Thanks for the reply! I think this package has its merits, being easy and straightforward to use. The issue is that not everyone expects every GitHub-specific behavior.

Maybe we need a plug-in mechanism to prevent the expansion of features and dependencies.

You may be interested in taking a look at my other issues, which aim for improving the structure of this project. Specially, I'm happy to work on this if #54 is accepted and deno-gfm would switch to remark.

[lino-levan]

The issue is that not everyone expects every GitHub-specific behavior

Personally I have to disagree on this one. If I (as the end user) see something render in GitHub, but not render in a page using this project, I would find that very strange. I am a big fan of the option bag we have which should alleviate the concerns regarding enabling unsafe or slow features (ex: math rendering).

Maybe we need a plug-in mechanism to prevent the expansion of features and dependencies.

I'm also -1 on this as well. It seems to me that functionality that people expect should really just be built-in. The only thing that makes me somewhat unsure about this is mermaid rendering but even then

• this should be through an option in the option bag
• it seems quite far off since it looks like Server Side Support mermaid-js/mermaid#3650 is getting no traction

[kidonng]

If I (as the end user) see something render in GitHub, but not render in a page using this project, I would find that very strange.

You would be hard-pressed to support every GitHub feature. For example, I dare you to try this one.

I am a big fan of the option bag we have which should alleviate the concerns regarding enabling unsafe or slow features (ex: math rendering).

That seems to be the opposite of "easy and straightforward to use". This is not Microsoft Word after all.

It seems to me that functionality that people expect should really just be built-in.

Well, it's just exporting parser options, not that complex/difficult?

[lino-levan]

For example, I dare you to try this one.

That actually seems really cool and relatively practical to me. I'll give it a shot at some point in the near future.

That seems to be the opposite of "easy and straightforward to use". This is not Microsoft Word after all.

Point taken

Well, it's just exporting parser options, not that complex/difficult?

If we're talking about remark plugins, this seems more reasonable. I had interpreted it as an in-house plugin system which seemed needlessly complex to me.

[kidonng]

That actually seems really cool and relatively practical to me. I'll give it a shot at some point in the near future.

It's going a little off-topic, but I'm not sure you want web requests in a Markdown parser...

If we're talking about remark plugins, this seems more reasonable. I had interpreted it as an in-house plugin system which seemed needlessly complex to me.

Does not have to be remark. And surely we are not building another parser here.

[lino-levan]

It's going a little off-topic

Yeah, sorry about that.

I'm not sure you want web requests in a Markdown parser...

We're a markdown renderer. If someone wanted to render some markdown in a GitHub style, I don't see why code references would be "too far".

Does not have to be remark.

I would like to move in that direction, but agreed.

surely we are not building another parser here.

👍

[hashrock]

First of all, thank you for discussing this. This discussion is useful to consider what features should be added in the future.
I think there are slight differences between the two use cases:

• A easy-to-use, battery-included gfm renderer.
  • Mainly for blogging
  • The rendered result needs to be as plain as possible.
  • It needs to support the formatting available on GitHub, because that's what users are used to.
  • The criteria for adding features to deno-gfm are as follows
    • It should be a commonly used feature (e.g. formulas, code highlighting, etc.)
    • Not add a lot of dependencies
• GitHub's Markdown rendering emulator
  • For deno.land/x or projects aiming single source
  • Must keep up with GitHub's Markdown rendering, which is updated frequently.
  • May need some styling customization features to blend the style of GitHub with the site being used.

Maybe the latter is a bit of a special use case. I don't think we should fork deno-gfm but we may not want to have the blog side affected by changes specific to deno.land/x.