Skip to content
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

Clarify ambiguity around "extensions" #3182

Open
webketje opened this issue Jan 30, 2024 · 1 comment
Open

Clarify ambiguity around "extensions" #3182

webketje opened this issue Jan 30, 2024 · 1 comment
Labels
category: docs Documentation changes good first issue Something easy to get started with

Comments

@webketje
Copy link

What pain point are you perceiving?.
There are 2 types of extensions with marked:

  • TokenizerAndRendererExtensions
  • MarkedExtensions

There are 3 (and more) signatures:

  • new Marked(extension, extension, extension)
  • marked.use(extension)
  • marked.use({ extensions: [TokenizerAndRendererExtensions] })

I was really confused by this and left me wondering whether the extension types had something in common (they don't). Then I realized TokenizerAndRendererExtensions are actually extensions options for MarkedExtensions.

Describe the solution you'd like
So I think something it would be better if the MarkedExtensions were renamed to MarkedPlugins or the option property extensions is renamed to tokenizerAndRendererExtensions. I mean, I don't really have a preference for a solution, but at least maybe prefix the word "extensions" in the doc with the type, so it is very clear which type of extention it is about. For example the docs have 2 sections "Known extensions" vs "Custom Extensions", but both talk about different types of extensions.

Context
I maintain @metalsmith/markdown which relies on marked and I'm working on upgrading to the latest version.
In that context I need to remap a single options object and pass some of them to marked. That means I need 2 config keys (eg 'markedExtensions', and 'tokenizerAndRendererExtensions') in an object to .use the plugins from a dictionary

@UziTech UziTech added the category: docs Documentation changes label Jan 30, 2024
@UziTech
Copy link
Member

UziTech commented Jan 30, 2024

Naming things is one of the hardest problems.

If you want to create a PR to update the docs, that would be great 😃 👍

@UziTech UziTech added the good first issue Something easy to get started with label Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: docs Documentation changes good first issue Something easy to get started with
Projects
None yet
Development

No branches or pull requests

2 participants