Description
Hello,
I have a few questions regarding this migration and would like to clarify whether updating the span class structure is an intended change for Rocket.Chat, especially since it appears to be referenced in related discussions in issues #24917 and #31069.
I am currently working on migrating the emoji implementation from emojione to emoji-toolkit. The required code changes are largely mechanical replacements (replacing emojione with joypixels) and do not introduce logic changes.
During this process, I encountered a few structural questions and some non-trivial decisions. It is not entirely clear what is expected in terms of scope, and clarification here would also help resolve the two related issues mentioned above.
Points Requiring Clarification
1. Asset Generation Scope
Should asset generation be included as part of the required PR, or is it preferred to introduce only the code-level support without handling asset generation?
For context, asset generation affects approximately 48,000 lines, which significantly impacts PR size and review complexity.
2. Span Class Structure
Currently, the EmojiOne implementation uses span classes formatted as:
emojione emojione-{category}
This is defined in:
meteor/app/emoji-emojione/getEmojiConfig.ts
The corresponding sprite files in the client directory follow the same naming pattern.
However, JoyPixels’ toImage method generates span classes in a different format:
joypixels joypixels-{size}-{category}
Is this migration expected to include updating the span class structure to match JoyPixels’ convention, or should the existing class pattern be preserved for compatibility?
3. File Naming Conventions
Many filenames are currently rooted with emojione (i.e., the name appears directly in file names). If emojione is no longer used, retaining those names may not make structural sense.
Should these filenames be updated to reflect emoji-toolkit, or is it preferred to preserve them for stability?
Since this impacts the overall scope and structure of the migration, I would like to clarify the expected approach and ensure that the changes align with the repository’s preferred workflow before proceeding further.
Thank you for the guidance.
Description
Hello,
I have a few questions regarding this migration and would like to clarify whether updating the span class structure is an intended change for Rocket.Chat, especially since it appears to be referenced in related discussions in issues #24917 and #31069.
I am currently working on migrating the emoji implementation from
emojionetoemoji-toolkit. The required code changes are largely mechanical replacements (replacingemojionewithjoypixels) and do not introduce logic changes.During this process, I encountered a few structural questions and some non-trivial decisions. It is not entirely clear what is expected in terms of scope, and clarification here would also help resolve the two related issues mentioned above.
Points Requiring Clarification
1. Asset Generation Scope
Should asset generation be included as part of the required PR, or is it preferred to introduce only the code-level support without handling asset generation?
For context, asset generation affects approximately 48,000 lines, which significantly impacts PR size and review complexity.
2. Span Class Structure
Currently, the EmojiOne implementation uses span classes formatted as:
emojione emojione-{category}This is defined in:
meteor/app/emoji-emojione/getEmojiConfig.tsThe corresponding sprite files in the client directory follow the same naming pattern.
However, JoyPixels’
toImagemethod generates span classes in a different format:joypixels joypixels-{size}-{category}Is this migration expected to include updating the span class structure to match JoyPixels’ convention, or should the existing class pattern be preserved for compatibility?
3. File Naming Conventions
Many filenames are currently rooted with
emojione(i.e., the name appears directly in file names). Ifemojioneis no longer used, retaining those names may not make structural sense.Should these filenames be updated to reflect
emoji-toolkit, or is it preferred to preserve them for stability?Since this impacts the overall scope and structure of the migration, I would like to clarify the expected approach and ensure that the changes align with the repository’s preferred workflow before proceeding further.
Thank you for the guidance.