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

[frissdiegurke]

Hey guys,

I've just published the first (except emoji-extended ) 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

[frissdiegurke]

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

[julian]

Now this is just plain cool...

[frissdiegurke]

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 .
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.

[julian]

@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

[frissdiegurke]

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

[julian]

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.

[frissdiegurke]

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

[julian]

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?

[frissdiegurke]

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

[PitaJ]

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

[frissdiegurke]

@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.

[rod]

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.

[frissdiegurke]

@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

[rod]

@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?

[frissdiegurke]

@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...

[Guest]

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
• 

[frissdiegurke]

@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.

[Guest]

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

[frissdiegurke]

@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.