Allow configurability for remark plugins

[Byloth]

Hi, everybody.

This discussion was born mainly from the issue remarkjs/remark-gfm#34 but, out there, seem to be a lot of issues that aim to the same target: Configurability.

Let's talk about it! 🙃

---

I've spent some time reading many other issues on many different projects and it seems to be normal behavior to avoid configurability.
To be honest, I'm still trying to figure out why this is; especially when they aren't adding new "strange" features but are simply being done to optionally disable a behavior and they aren't breaking changes.

I understood the point of view used in these cases:

«Unified is like LEGO bricks; you can do whatever you want.»

... while, at the same time, I'm always asking myself:

• «Why do I need to fork a well-maintained project, that I can rely on, just for changing a "comma"?»
• «Why do I have to spend the effort to keep a fork -only used by me- aligned and updated to all these bricks?»
• «Isn't it worth more to spend the same effort to contribute to a project used by thousands of people?»
• «What's the good of this kind of fragmentation?»
• «Is configurability really that bad?»
• «What are they seeing that I can't see?»

---

I also understood that Unified is like LEGO and that I can do whatever I want...
And I'll be extremely happy to contribute if, someday, I implement a new kind of plugin like no one out there...

BUT...
For example, in these few cases, is it really worth it forking the original projects?

• remark-gfm-without-autolink
• remark-gfm-without-email-autolink
• micromark-extension-gfm-tagfilter-except-iframe

Obviously!
I'm not saying that all of these issues are absolutely valid (although in my opinion they're); I just want you to put the aim on Configurability.

Suppose, now, that there's no configurability even in those plugins that already support it:

• Would it ever make sense to split remark-frontmatter into remark-frontmatter-toml and remark-frontmatter-yaml?
• Would it ever make sense to split remark-html into remark-html-raw and remark-html-sanitized?
• Would it ever make sense to split remark-images into remark-images-jpg, remark-images-png, remark-images-svg, ecc...

... and these are just 3 examples that, ironically, correspond extremely well to the original issue in which this discussion arose.

---

I think that configurability is a MUST and that this kind of fragmentation is absolutely to avoid... Especially in an open-source project.

Here's an example of a similar situation, also related to configuration, within another open-source project.
I could have forked it for this, solving my problem... But the team, IMHO, handled it very well!

nuxt/content#1116

---

I don't think that this kind of configurability is that bad...
But, am I the only one who thinks so? 🤔

[ChristianMurphy]

Taking a step back, the answer likely lies in the question @wooorm suggested in remarkjs/remark-gfm#34 (comment)

If you have a problem, share your problem in a constructive manner by opening a discussion: I want to achieve A, I’ve though about B and C but it doesn’t work because of D, anyone have any recommendations?

Pushing for a solution without articulating the problem is not an effective way of solving the problem.

---

Some broader context which can help set the stage.
Remark plugins broadly fall into a few categories.

• Parser plugins, which add new syntax features
• Transformer plugins, which work with existing content types
• Presets, which bundle parser plugins and/or transformer plugins together

remark-frontmatter is an example of a parser plugin.
remark-images is an example of a transformer plugin.
remark-gfm and remark-html are examples of presets.

Parser plugins and transformer plugins sometimes have configuration, in limited cases and where appropriate.
Presets generally do not, they are intended as a combination of plugins configured for a specific use case.

Taking the example of remark-gfm, most of the requests come down to wanting configuration, actually want another flavor of markdown, like: GitLab flavored markdown, Slack flavored markdown, Python flavored markdown, etc.
Each of those are perfectly valid wants.
It doesn't make sense to shove those into the GitHub flavored markdown preset, even as options, those are their own distinct flavors of markdown, which should have their own presets.
And remark supports this, by having the different pieces of the parser broken into composable blocks, which can be added together to form these other flavors if wanted/needed.

[Byloth]

Hi, @ChristianMurphy!
Sure, no problem... I'm right here to give you all the information you need. 🙃

Let's start by quoting another comment from @wooorm on the same issue:

I want markdown to become easier, more uniform, more “standard”. I.e., matching CommonMark and GFM. Not the funky language whatsapp or slack has.

This sentence is the core of it all: «I want Markdown to become [...] more standard. [...] Not the funky language WhatsApp or Slack have.».

How many times are you writing something that doesn't necessarily have to be a link (e.g. www.eee) and:
«Oh... That's clearly a link! Let me create automatically the hypertext for you!»?

This is exactly what a funky language looks like. That's it.
Say whatever you want; this is exactly like WhatsApp.

GFM is extremely good... Except for this single funky thing (that should be configurable, IMHO).

---

My users are developers, technicians and other IT figures that KNOW how to write Markdown WELL.
Some of them, asked for the ability to disable this funky behaviour while keeping all the other GFM features.
I've already implemented it, of course...
Just like other people... The same thing... Over and over...

This is the purpose of this discussion: to add a simple configuration to a known and reliable repository, preventing other people from doing the same thing over and over on their own repositories...
Typically left in its state since the project closed, no longer maintained by anyone, a possible source of security breaches and certainly not a reliable repository that other people can rely on.

That's not the FOSS I want to see in the World.

---

Again...

I understood that this configuration would change the "flavor" of the presets... Of course...
But is it REALLY that bad?

And also... Isn't configurations born just for this reason?
Typically, when someone specifically changes some configuration of something, he knows what he's doing... Isn't it?

[ChristianMurphy]

Sure, no problem... I'm right here to give you all the information you need.

Then please answer the questions, rather than avoiding them.

This is exactly what a funky language looks like. That's it.

If you disagree with with what features GFM includes, that would be something to raise with GitHub itself, as the maintainers of the GFM standard https://github.com/github/feedback

I understood that this configuration would change the "flavor" of the presets... Of course...
But is it REALLY that bad?

Yes, it really is that bad.
Standards are moving targets.
For example GFM has recently added Mermaid and Math (https://github.blog/2022-05-19-math-support-in-markdown/ and https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/)

The aim of remark-gfm is to match the GitHub favored markdown standard.
The aim of people who want to customize is to implement a different standard.
Standards will diverge over time, features in GFM aren't necessarily added to GitLab flavored markdown, Slack markdown, Whatsapp markdown, Python markdown, etc.
And as such, any and every change to remark-gfm would be a breaking change for the other flavors, needing more customization and disables to update (even on minor or patch versions).

Your arguments around maintenance, security, and support all revolve around GFM being static.
But it isn't, it changes regularly, and that change would require each and every downstream adopter who wants a custom flavor to manually disable the new plugins, in the specific way needed for their project, every single release.

In other words, none of the issues you mention would be solved by configuration in remark-gfm, the same problem would continue to exist, and in addition the project would be larger and more complex for naught.

[wooorm]

How many times are you writing something that doesn't necessarily have to be a link (e.g. www.eee) and:
«Oh... That's clearly a link! Let me create automatically the hypertext for you!»?

I have not have this happen. I know the edge cases because I reverse engineered the algorithm so you're right that it's not pretty. But I haven't seen the edge cases pop up in my writing.

If your authors are programmers, that know how to write markdown as you say then I believe they are wrong,
for wanting to remove one feature from GFM. You don't remove one feature from HTML or CSS or JS either. If they care about markdown they should care about compatibility.

The solution to bad autolinking is not to turn it off. The solution is:
a) if you see it as a bug, report it to GH, as Christian mentions, and potentially use 'patch-package'
b) potentially build a better autolinker yourself. And build some more things you like better yourself. And make your own markdown flavor. And package that up in your own package.