Open JoshuaKGoldberg opened 11 months ago
@JoshuaKGoldberg I really like the idea of making the library more extensible and it would likely solve a lot of issues people are having with the library not supporting certain codes for certain emoji. I also agree that returning a new object with the same APIs as node-emoji is the way to go. That way you could even have multiple instances of node-emoji that all resolve them differently. It is way more flexible and less prone to tricky bugs that can arise from modifying the global state of the library.
One month and no additional inputs - marking as accepting PRs! 🚀
Note that this probably isn't a trivial change. It'll require making all sort of stuff in node-emoji per-instance.
I quickly implemented a solution that updates the global state, but I'm wondering if anyone knows a way to create a new instance without having to modify the entire library?
Forking @bigpay-ali's https://github.com/omnidan/node-emoji/pull/132#discussion_r1368079440:
I like this idea. Even after the latest emojilib gets merged in, it's possible folks will want to add their own context/project-specific emoji extensions.
One difficulty with this is that right now, all
node-emoji
APIs are exported standalone: e.g.import { findByName } from "node-emoji"
. This new extension API would need to either:node-emoji
moduleI'd lean towards the latter personally, as modifying global state is a worrisome thing to me.
My starting API proposal:
This differs from the original comment by being more explicit and open to later expansion, at the cost of extra verbosity.