Extract text and link from inline links

[tafel]

Hello,

For inline links extraction, the current behaviour is to replace [text](http://link.net) either by text (replaceLinksWithURL = false) or by http://link.net (replaceLinksWithURL = true).

Is it possible to print both text and link, like text: http://link.net ?

Maybe with an option separator?

Options should be like:

const plainText = removeMd(markdown, {
  separateLinksAndText: ': ' // default to null
})

// in index.js, something like
if (options.separateLinksAndText) {
  output.replace(/\[([^\]]+)\]\(([^)]+)\)/g, `$1${options.separateLinksAndText}$2`);
}

Thanks

[NotYoojun]

Instead of keeping separateLinksAndText as a dedicated separator option, I think a more flexible design would be to allow a single argument that can handle multiple cases. For example, users could pass:

• boolean => simple on/off switch (current behavior)
• string =? use a custom separator string
• function => full flexibility, where the function receives the link/text and returns the desired output

This approach would avoid adding more flags in the future and give developers a consistent, extensible way to control how links and text are handled.

[tafel]

@NotYoojun Could you provide an example for the function usage?

remove-markdown accepts a string and returns a string. You can have all the desired flexibility by transforming the string before (or after) calling remove-markdown.

I'm not sure the function is useful to be integrated inside the library.

[zuchka]

I think less is always more with a library like this.

[NotYoojun]

@NotYoojun Could you provide an example for the function usage?

remove-markdown accepts a string and returns a string. You can have all the desired flexibility by transforming the string before (or after) calling remove-markdown.

I'm not sure the function is useful to be integrated inside the library.

The problem is that neither the input or output is structured and can be manipulated conveniently.

While pre/post‑processing works, it forces every consumer to reinvent the same wrapper logic, many developers will want to tweak link handling in slightly different ways.

// Proposed API
removeMarkdown(input, {
  linkSomethingOrWhateverName: (text, href) => `${text} (at ${href})`
});

// vs. current workaround
const stripped = removeMarkdown(input);
const custom = stripped.replace(/.../, ...); // user must re‑implement parsing

I understand the concern about adding complexity. My suggestion is really meant to be lightweight: if integrating the function mode can be done easily within the current implementation, then it could be added as an optional, opt‑in feature. In that case, it’s “the more the merrier”: users who need extra flexibility get it without affecting the default behavior.

If, on the other hand, supporting this would require major refactoring or a big rewrite, then I agree it’s not worth pursuing. The idea is only to provide additional flexibility if it can be slotted in naturally.