[nodebb-plugin-emoji-extended] Emoji Extended (reworked)

NodeBB Plugins
  • Hey guys,

    I've just published the first (except emoji-extended xD ) releases of

    • nodebb-plugin-emoji-extended (GitHub)
    • nodebb-plugin-emoji-one (GitHub)
    • nodebb-plugin-emoji-cubicopp (GitHub)
    • nodebb-plugin-emoji-static (GitHub)
    • nodebb-plugin-emoji-apple (GitHub)

    All of those depend on nodebb-plugin-emoji-extended@^1.0.0 being installed.
    Take a look at the ACP settings of nodebb-plugin-emoji-extended to see and feel all improvements 😉

    The (un)install buttons are currently not working and thus disabled.

    Feedback is always welcome.
    Here is my current TODO list:

    Emoji Static
     * [s/c] show alert with reason of error when index not found
     * [s/c] image upload
     * [s/c] ACP details-handling (deprecate *index.json*)
     * [c] multiple sets management
    Emoji Extended
     * [s/c] enable within signatures (including auto-completion)
     * [s] allow sets to specify outdated files (e.g. index-file check), indicate within ACP
     * [s/c] allow user to specify prefix/suffix for auto-completion per set, auto-create suffix (setId) for overwritten emoji
     * [c] check markdown-alternatives for code-block detection implementation
     * [s/c] allow alternate image source for modal (e.g. sprites image)
     * [s/c] ACP page
       * [c] add sort capability of active sets
       * [s/c] indicate busy-state on page-load
       * [s/c] implement [un]install actions
       * [s/c] show modules that are installed but not enabled within NodeBB (on top of available sets)
         * [s/c] implement activation action
       * [s] filter modules for installation that ain't compatible with NodeBB version
     * [c] (maybe) markdown check rework
     * [s/c] (maybe) push-update styles on sets-update, append to already in-use styles
    Emoji One
     * [s] parse unicode emoji characters
    New Sets
     * twemoji
     * PhantomOpenEmoji
     * emojisymbols.com

    Of course if you want to contribute, feel encouraged to send a PR or even publish your own sets 😉

  • PS: An introduction on creating new sets can be found here.

  • Now this is just plain cool...

  • However I'm not sure in which way NodeBB should/could keep emoji-extended within its dependencies.

    If emoji-extended is listed (and activated by default), some unused client-side code gets delivered.
    If emoji-extended and non-static set(s) are listed (and activated by default), that/those set(s) would still need to update files by hand via emoji-extended ACP page.

    The options that come to my mind:

    1. list emoji-extended and a static set (emoji-cubicopp is the only one right now); add that set to default settings of emoji-extended therefor it is activated by default.
    2. list emoji-extended and a non-static set (emoji-one would be my choice); add that to default settings; call its update() function within ./nodebb setup; I could add a callback-based variant for that set if you want to avoid promises within core.
    3. list emoji-extended and a non-static set; add that to default settings; call its update() function on server start (static:app.preload I assume) if no files are present.
    4. list emoji-extended; do not enable it by default
    5. drop emoji from dependencies

    The 3rd would break my clear distinction between plugin installation and image files o_O .
    I tend to the 5th; Adding the word "smiley" to the description of emoji-extended should ease the search within the plugin-list.
    It would be great if NBBPM could handle peerDependencies starting with nodebb-[...]- properly (or does it already?) for this case.

  • @frissdiegurke No way, the last time I added a peerDependencies property to my package.json, things went sideways really really quickly.

    It's deprecated in npm3, and I'm not touching that property with a ten-meter pole 😆

  • @julian deprecated? you sure? the docs only specify a behavior change that those are not installed automatically

  • Perhaps you're right -- in any case, I was initially drawn to peerDependencies because it seems like a good way to handle sideways dependent packages, but it didn't work at all in practice, so I've abandoned its usage.

  • @julian Since npm 3+ don't handle peerDependencies other than outputting warings, you might consider giving it a try again 😄
    Otherwise (to keep stuff working with 2-) we could add a field like nbbpm.dependencies...

  • Dependency management is definitely not something I want to get into 😆

    Perhaps do a module.parent.require('nodebb-plugin-emoji-extended') and error out if it returns null? 😄

  • @julian That's the current state, also using peerDependency. Was just a thought that auto-installing those dependencies would be more comfort 😉

  • @frissdiegurke with npm@3, since node_modules is flattened, you can install things as normal deps and they should work as peer deps.

  • @PitaJ But only as long all version ranges match a single version, if they don't it communicates with a "silent" nested nodebb-plugin-emoji-extended which would probably cause much confusion and thus I don't want this 😉 The main problem is that NodeBB at some point breaks the distance to NPM by depending on the node_modules structure (of which I cannot come up with an alternative way of course). This makes it impossible to solve the issue with NPM only. It has to be either a peerDependency which will not install the package if it misses, but does not cause other possible trouble or a solution via NodeBB itself. Since NodeBB breaks the distance to NPM it should be responsible for that breakpoint. At least these are my thoughts of it.

    A fixed dependency would also disrespect the nbbpm.compatibility of nodebb-plugin-emoji-extended which might cause even more trouble.
    I think as long NodeBB does not provide a better way, going with peerDependency and a notice within the plugins descriptions is the best I can do.

  • Upon installing nodebb-plugin-emoji-apple I see in my log this error:

    26/2 10:35 [10738] - error: [plugins/emoji] nodebb-plugin-emoji-extended is not installed. nodebb-plugin-emoji-apple depends on it.

    I do have nodebb-plugin-emoji-extended installed. To make sure nothing was wrong with the base emoji-extended plugin i removed it and the newly installed emoji-apple plugin, reloaded NodeBB, and re-installed but still receive this warning message.

    It seems that the plugin is working though but feel that I should report this as something maybe wrong that I haven't found yet.

    Thank you.

  • @rod I assume you have any nodebb-plugin-emoji-extended less than 1.0.0 installed. I should precise that message o_O
    FYIL: to install any ^1.0.0 version you currently have to remove it from the package.json file 😉

    And if this is the case it's not using the nodebb-plugin-emoji-apple at all 😛

  • @frissdiegurke Ah yes, you are correct. emoji-apple is not working b/c I have 0.4.17 of emoji-extended.

    Should I wait until NodeBB is 1.0.x to have a seamless installation of emoji-extended@^1.0.0?

  • @rod If you're on master you can install it without any problems, just need to remove that listing within package.json (you'll have to git reset --hard before future git pull to avoid problems with git).
    If you're on another branch (e.g. 0.9.x) it's probably not working to its full potential. For example I think you'd have to update the composer too in order to get auto-completion...

  • Here's an interesting bit of behavior 😛

    • Upgraded to 0.9.4.
    • Removed dependency from package.json
    • NPM i nodebb-plugin-emoji-extended@latest
    • Installed nodebb-plugin-emoji-apple
    • Broken emojis
  • @ThingBreaker
    Are the emoji working within posts/previews? If not, check your config.json for the url property.
    I'm not sure why the translations of modal.title and modal.legal are not working, will take a look at that.

  • @frissdiegurke It looks like the URL was malformed and after correcting it, emojis are back up and running.

  • @ThingBreaker And as to the translations it seems the defaultLang support of v0.9.x is failing.
    Since it's a minor 0.9.x issue and I'm supporting ^1.0.0 only, it's not gonna be fixed from my side. Maybe the @administrators want to merge the fix of defaultLang into 0.9.x, but I wouldn't bet on this 😉 . I guess it's something one can live with until next major NodeBB release.

Suggested Topics