3.0.0

[muan]

I plan to introduce a few breaking changes to emojilib in order to contain the scope of this project. In short, this project should only be adding keywords to emoji, and nothing more. This means:

• New emoji added to Unicode should come from muan/unicode-emoji-json, instead of manually added here. (Updating list #125, Idea: List Unicode version for each emoji #126)
• Use emoji sequence as identifier instead of made up emoji name, since they don't have official machine friendly names. (Some countries don't use their name. #131, Flag names inconsistent with some other libraries/apps #135,)
• Both simplemap.json and ordered.json will be removed, since they have nothing to do with emoji keywords. They can be generated from muan/unicode-emoji-json if people want it.
• Point main to JSON instead of a node interface.
• Bonus: generate language based emoji-keyword mapping based on Unicode CLDR. (Internationalization API #12)

TODO:

• Generate new JSON based on Unicode data
• Create CLI for updating dataset

cc @jasonrudolph FYI

[jasonrudolph]

Nice! ⚡

[jsumners]

Do I understand correctly that the new version will export a hash like?:

{
  "😀": {
    "keywords": ["face", "smile", "happy", "joy", ":D", "grin"],
    "name": "grinning",
    "fitzpatrick_scale": false,
    "category": "people"
  }
}

Is there an ETA on this work?

[tonnoz]

any news? Looking forward for this release 😀

[tcd]

Wondering what's blocking this?

[muan]

Wondering what's blocking this?

My burnout state of mind unfortunately. :)

Do I understand correctly that the new version will export a hash like?:

Looks like this is where I left it:

emojilib/dist/emoji-en-US.json

Lines 2 to 10 in e3b4c85

	"😀": [
	"grinning_face",
	"face",
	"smile",
	"happy",
	"joy",
	":D",
	"grin"
	],

Looking back now though I can see how this is not desirable for existing consumers of this library, as they would need to pull in an alternate source for other emoji metadata (hence the MAJOR version bump).

IIRC, I made this decision because people often request features like "shortcode used for <github/discord/slack/etc> service", which I consider out of the scope of this project. To work around this they'd have to pull in other libraries that do this. This seems tedious, but given that the emoji dataset is gigantic and will only grow in the future, I feel like this is for the best.

I know there are the swiss army knife type of emoji data libraries out there. An ideal scenario would be that they pull this dataset in instead. I'd personally love to see a emoji module that let you build your own dataset.

buildEmojiData --fields character,keywords,unicodeVersion,githubCode --format json

Maybe this already exist, I don't know. But this is more than what I feel comfortable taking on.

So once this is merged, I imagine that I'll be doing something like this for my own use cases:

const emojiData = require('unicode-emoji-json') // https://github.com/muan/unicode-emoji-json/blob/master/data-by-emoji.json
const keywordData = require('emojilib') // needs a better name to clarify purpose

for (const emoji in emojiData) { // 😀
  const keywords = keywordData[emoji] // ["grinning_face","face","smile","happy","joy",":D","grin"]
  return html`<button data-keywords="${keywords.join(' ')}">${emoji} ${emojiData[emoji]['name']}</button>`
}

Any thoughts?

[jsumners]

@muan I think your approach is the right one. I came to it naturally as well when I investigated the travesty that is this spec (https://twitter.com/jsumners79/status/1211105577188970497). Like you, I haven't had the time or constitution to get back to it. But my idea was to write a tool that will read all of the base spec files and mash them into something usable.

[muan]

think your approach is the right one.

👍

write a tool that will read all of the base spec files and mash them into something usable.

muan/unicode-emoji-json does mostly that with 3 files already, but no CLDR:

https://github.com/muan/unicode-emoji-json/blob/2e9838abfc854890a155957b8ca5dff650f24de6/script/download-unicode-data.js#L10-L17

[jsumners]

I think I was using CLDR to include skin tone variations.

[BrianHung]

Looking back now though I can see how this is not desirable for existing consumers of this library, as they would need to pull in an alternate source for other emoji metadata (hence the MAJOR version bump).

This makes sense, and it's already what I'm doing. I also saw that Emoji Mart is doing the same. A good source for normal emoji metadata (no keywords) we both used is emoji-data.

[muan]

Apologies for the delay. Here's the new dataset.