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

Ampersand in link query strings unexpectedly escaped with backslash #1196

Closed
4 tasks done
delucis opened this issue Aug 5, 2023 · 5 comments
Closed
4 tasks done

Ampersand in link query strings unexpectedly escaped with backslash #1196

delucis opened this issue Aug 5, 2023 · 5 comments
Labels
🙅 no/wontfix This is not (enough of) an issue for this project 👎 phase/no Post cannot or will not be acted on

Comments

@delucis
Copy link

delucis commented Aug 5, 2023

Initial checklist

Affected packages and versions

remark@14.0.3 — also tested with 13.0.0, 14.0.0, and 14.0.2 with the same results.

Link to runnable example

https://codesandbox.io/s/remark-ampersand-escaping-repro-6mm6xg

Steps to reproduce

  1. Create a Markdown string, containing a link with a query string. For example:

    const md = '[label](https://github.com/search?type=code&q=remark)';
  2. Process the string with remark:

    const file = await remark().process(md);
  3. Inspect the result:

    console.log(String(file));
    // [label](https://github.com/search?type=code\&q=remark)

Expected behavior

The original link and query string should remain unchanged.

Actual behavior

The & in the link’s query string is escaped with a \, breaking the link. (Perhaps this is intentional for a reason I don’t understand, but it was unexpected to me.)

Runtime

Node v16, v18, v20

Package manager

npm 8, pnpm

OS

Linux, macOS

Build and bundle tools

Rollup, esbuild, Parcel, Vite — tried a bunch of different environments to confirm behaviour.

@github-actions github-actions bot added 👋 phase/new Post is being triaged automatically 🤞 phase/open Post is being triaged manually and removed 👋 phase/new Post is being triaged automatically labels Aug 5, 2023
@wooorm
Copy link
Member

wooorm commented Aug 5, 2023

Hey!

This is intentional. &, depending on what comes after it, could turn into a character reference. E.g., when copy; comes after it, it turns into something else.

breaking the link

The link is not broken. Markdown parsers support escapes.


For more info, see for example syntax-tree/mdast-util-to-markdown#53.

@wooorm wooorm closed this as not planned Won't fix, can't repro, duplicate, stale Aug 5, 2023
@wooorm wooorm added the 🙅 no/wontfix This is not (enough of) an issue for this project label Aug 5, 2023
@github-actions

This comment has been minimized.

@github-actions github-actions bot added 👎 phase/no Post cannot or will not be acted on and removed 🤞 phase/open Post is being triaged manually labels Aug 5, 2023
@delucis
Copy link
Author

delucis commented Aug 5, 2023

Thanks for the response! My rehype pipeline is still ending up with the bad link in the rendered content, but I’ll dig a bit deeper to figure out that bit. Nope, this also wasn’t true, things are actually working as expected, we just misattributed the real cause of an error to that sneaky looking \. Apologies for the disturbance and thanks again! 🙌

@wooorm
Copy link
Member

wooorm commented Aug 5, 2023

No worries!

Could you share the actual problem with me? I'd appreciate hearing your root cause for future strugglers!

@delucis
Copy link
Author

delucis commented Aug 5, 2023

Mostly human error! 😅

We have a pipeline that pulls in some Markdown, processes with remark and a bunch of plugins, and then stores the resulting Markdown for rendering later. We were struggling with migrating some links where the search parameter syntax had changed and noticed “Oh there’s this \ in some of them after processing.” This led us to misattribute that as the cause for some link breaking (because naively copying a link like that does break) and debug to work out what was introducing the \ (assuming it to be one of our plugins, but later realising it was remark itself). You mentioned “Markdown parsers support escapes”, so that made me double check and realise this was the wrong rabbit hole and the final <a> in our rendered content was correct 😁

Anyway — appreciate your fast response. Helped get us back on track 💜

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🙅 no/wontfix This is not (enough of) an issue for this project 👎 phase/no Post cannot or will not be acted on
Development

No branches or pull requests

2 participants