Heading anchor slug does not respect GitHub behavior due to emojis
Discussed in #9193
Considering the heading ## :smiley: This is a friendly header
Our slugger package is supposed to align with GitHub and seems to work as intended (the input heading string is not supposed to contain the leading space):
expect(slugger.slug(' This is a friendly header')).toBe(
'-this-is-a-friendly-header',
);
expect(slugger.slug('This is a friendly header')).toBe(
'this-is-a-friendly-header',
);
expect(slugger.slug(' :smiley: This is a friendly header')).toBe(
'-smiley-this-is-a-friendly-header',
);
expect(slugger.slug(':smiley: This is a friendly header')).toBe(
'smiley-this-is-a-friendly-header',
);
// Yes, that's how GitHub behave in this case
expect(slugger.slug('😃 This is a friendly header')).toBe(
'-this-is-a-friendly-header',
);The MDX Playground shows the heading is parsed this way, and it's the value we pass to our slugger:
{
"type": "heading",
"depth": 2,
"children": [
{
"type": "text",
"value": ":smiley: This is a friendly header"
}
]
}
What I understand:
We should probably use node-emoji to "unconvert the value" before passing it to the slugger.
import * as emoji from https://github.com/omnidan/node-emoji,
slugger.slug(emoji.unemojify('😃 This is a friendly header'));The problem is that we shouldn't always unemojify 😅
If you look at the GitHub behavior, it has a different slugging behavior if we use 😃 or :smiley: in a heading:
See https://gist.github.com/slorber/9c499bb934434a3f7ac6603eff6647d3#-this-is-a-friendly-header-real-smiley
We should align to this behavior, but I'm not sure how 😅
The solution would be to get the "original" heading string value before remark-emoji gets applied. I'm not sure remark-emoji outputs that original value currently.
Heading anchor slug does not respect GitHub behavior due to emojis
Discussed in #9193
Considering the heading
## :smiley: This is a friendly header#smiley-this-is-a-friendly-headerfor your headerOur slugger package is supposed to align with GitHub and seems to work as intended (the input heading string is not supposed to contain the leading space):
The MDX Playground shows the heading is parsed this way, and it's the value we pass to our slugger:
What I understand:
😃 This is a friendly headerWe should probably use node-emoji to "unconvert the value" before passing it to the slugger.
The problem is that we shouldn't always unemojify 😅
If you look at the GitHub behavior, it has a different slugging behavior if we use
😃or:smiley:in a heading:See https://gist.github.com/slorber/9c499bb934434a3f7ac6603eff6647d3#-this-is-a-friendly-header-real-smiley
We should align to this behavior, but I'm not sure how 😅
The solution would be to get the "original" heading string value before remark-emoji gets applied. I'm not sure remark-emoji outputs that original value currently.