Hi @Ry-DS ! Thanks a lot for the PR.

:octocat: doesn't work because :o turns to :open_mouth. There are some more emojis like this. Let me know if you have a good solution to this...

Based on https://github.com/tommoor/react-emoji-render/blob/master/src/renderer.js#L76, if we have the github aliases in our dataset, we should not have that issue. I understand this is an edge case as Github emojis are not part of the unicode standard and we can't really have entries in that file without a matching unicode emoji, but I think your customAliases approach is very interesting for this use case. Maybe if you add another condition at https://github.com/tommoor/react-emoji-render/blob/master/src/renderer.js#L84 checking if there is a match with some of the custom aliases it's enough to make it work without any further modification in the replaceAliases function.

@Ry-DS any chance you pull this off to an end ?

@enzoferey hey! Thanks for the reminder. I did a quick commit which I think fixes it, definitely take a look and confirm if you think its an ok solution. If so, I plan to polish it up with comments later today and it should be g2g.

@enzoferey just bumping this, let me know if you need anything else from my end (I should be a little more active to any requests this and next month) :)

Hey @Ry-DS , thanks for the follow up, this is far from a priority for me 😅

Reading again the comments above and your code, I had something very specific in mind that should reduce the complexity of the chances introduced and enable future similar use cases to integrate in the same way. Quoting my previous message:

Maybe if you add another condition at https://github.com/tommoor/react-emoji-render/blob/master/src/renderer.js#L84 checking if there is a match with some of the custom aliases it's enough to make it work without any further modification in the replaceAliases function.

So far you have changed a lot about how the replacing and rendering algorithms work, but I think just introducing a single check on the customAliases props could solve it all.

Also, we are introducing a lot of useless tests on the different vendors that only affect the Github component, we should improve that don't you think so ?