One of the best things about Node.js is its massive module ecosystem. With bundlers like webpack we can leverage these even in the browser outside ...
For further actions, you may consider blocking this person and/or reporting abuse
There's an error in your regex string. It should be
var EMOJI_SHORTCODES = /:[a-zA-Z1-9_]+:/g;You've forgotten the
+at the end of the[]Ah it was dropped during the import from the other blog. Thank you!
Watch out –
prepublishis deprecated: docs.npmjs.com/misc/scripts#deprec...Should
@types/emojionebe dev dependency?prepublishitself is not deprecated. The old behavior is deprecated. But it's not the behavior that I'm intending here.No the
@types/emojioneshould be a normal dependency because it's a dependency of the generated.d.tsfile. Basically the@typesof any regular dependency should also be a regular dependency.prepublish: right. npm’s deprecation warning gave me the wrong impression. I’m usingprepublishOnlyto avoid that warning, but it looks like that will be deprecated in the long run, whileprepublishwill stay (withprepublishOnlybehavior): github.com/npm/npm/issues/10074@types/emojione: make sense, didn’t know about dependencies between type definition files.In this case it doesn't make a difference whether
@types/emojioneis a dev dependency or not because the.d.tswill only expose one signature that has only built-in types. But if we would have a function that for example exposes aBufferas part of one signature and we would need@types/nodeas a normal dependency since the generated.d.tsfile has a connection to it. So the best practice would be to just do it for all dependencies that you actually use during runtime.Your last code example has one to many ( in it
findEmojis((
Hello 🐵! What's up? ✌️);Good catch! thanks!