-
-
Notifications
You must be signed in to change notification settings - Fork 241
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
Add a .extend(...) option to expand upon the built-in dictionary #144
Comments
@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. |
Forking @bigpay-ali's #132 (comment):
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.
The text was updated successfully, but these errors were encountered: