twemoji: Maxcdn has shut down, cdn not working anymore.

FYI how to use jsDelivr to serve twemoji images:

twemoji.parse(
  document.body,
  { base: 'https://cdn.jsdelivr.net/gh/twitter/twemoji@14.0.2/assets/' }
)

The CDN is back online! All previous URLs will continue to work and redirect to jsDelivr e.g. https://twemoji.maxcdn.com/2/svg/1f525.svg

Stackpath reached out to @jsDelivr and changed the DNS CNAME to point to a CDN we control.

Yeah, we didn’t exactly get a chance to hand anything over before getting laid off. Usually a company with the ability to plan business operations would allot time for that, but we all got spontaneously locked out of our computers in the middle of the night, so. Poor handover would imply having tried to hand over. 🥲

The regex comes from https://github.com/twitter/twemoji-parser, where I open sourced the Scala generator for the regex last year so we aren’t missing anything there. It also has the same problem of the default options being broken due to MaxCDN, but specifying another path is possible as an option. Assets are kept only in twemoji not twemoji-parser. For longer term maintenance beyond just this one issue, we’d eventually need to fork twemoji-parser too for regex updates – I have NPM publish access to it, but there actually seems to be nobody left with GitHub write access who previously committed to it.

I’d be pretty sad to deprecate Twemoji honestly, especially when the designer is willing to work on a fork of it with me. I was hoping to get wherever I worked next to adopt Twemoji though, so the details are a little up in the air. Maybe we just fork now for compatibility but without substantial support, although I know that would annoy some people.

@simplexx among all the things, twemoji has always been a Twitter service for the community.

At my times in there, we had a great agreement / deal with MaxCDN so that it’s hard to blame the boss this time, as MaxCDN is a completely different company/story.

What I see is some poor attention to this project, as companies don’t close from a day to another (usually?) but as we all know what’s going on @ twitter, I can’t really blame any of my former colleagues, or new arrivals there.

Please let’s not make it a wall of shame for all the people that worked on this, thanks for your understanding (I’ve left 7 years ago or more, as example, I’ve got pinged by some follower and I’m just trying to help you out anyway).

Drop-in replacement for Twemoji: https://github.com/AdvenaHQ/fluent-emoji

I’ve published an official fork of Twemoji at @twemoji/api on NPM, starting at v14.1.0. The default CDN is jsDelivr, so this issue (#580) is resolved. The code for the fork is hosted on GitHub here. Similarly, an official fork of twemoji-parser is available at @twemoji/parser on NPM and that code is hosted on GitHub here.

Feel free to keep using Twitter’s twemoji and twemoji-parser, but I don’t have any more planned updates to it.

FYI @WebReflection I’ve also invited you to the NPM organization and given you commit access to the fork, so go accept it if you like.

@unvented and I connected over Discord and we’re all set now. Thanks again! I’ve deleted the comment with my contact info to minimize unsolicited messages.

Here is an alternative to the essentials of the Twemoji library in less than 10 lines:

const emojiFinder = /(\u00a9|\u00ae|[\u2000-\u3300]|\ud83c[\ud000-\udfff]|\ud83d[\ud000-\udfff]|\ud83e[\ud000-\udfff])/g;

export default function parse(html: string) {
  return html.replace(emojiFinder, (match) =>
    `<img alt="${match}" src="https://abs-0.twimg.com/emoji/v2/svg/${
      (match.codePointAt(0) ?? 0).toString(16)
    }.svg">`,
  );
}

For everyone else looking for the quick and dirty summary fix:

<script src="https://cdn.jsdelivr.net/npm/twemoji@14.0.2/dist/twemoji.min.js"></script>
<script>
  twemoji.parse(document.body, { base: 'https://cdn.jsdelivr.net/gh/twitter/twemoji@14.0.2/assets/' });
 </script>

For what it’s worth, while I was still there we were in talks with MaxCDN to have the same deal when they migrated to be Stackpath. Everyone who had worked on the deal with MaxCDN had left and left no record of that deal, so it was taking them a bit longer to work out than expected – MaxCDN used to offer free hosting to OSS projects, but Stackpath wouldn’t be doing that. They were working on an exception for us, but any emails they send to our Twitter emails now get bounced, so I guess they could’ve gotten this sorted out before shutting down MaxCDN… but it’s not like we’re there on the other end to make it happen, so it appears we’ll never know.

quick look at the code shows that this url is configurable, see https://github.com/twitter/twemoji/blob/d94f4cf793e6d5ca592aa00f58a88f6a4229ad43/scripts/build.js#L551 try pass parameter ‘base’ in options(second parameter) for parse method for example

result = twemoji.parse(segment.text, {
  folder: 'svg',
  ext: '.svg',
  base: 'https://cdnjs.cloudflare.com/ajax/libs/twemoji/14.0.1/'
});

should work (works for me with react-twemoji, which uses twemoji 14.0.1

If you don’t want to use a fork, this was my hot fix in the one place we used twemoji:

result = twemoji.parse(segment.text, {
  folder: 'svg',
  ext: '.svg',
});
// temporary fix because maxcdn has stopped supporting twemoji
return result.replace(
  'twemoji.maxcdn.com/v',
  'cdnjs.cloudflare.com/ajax/libs/twemoji',
);

@jdecked If you need any help or want any additional maintainers my company is willing to put resources behind it to keep it open sourced and update it (as I stated above). We use it a lot on our product and would be more than happy to contribute to help improve it.

I’m gonna make a PR. The images doesn’t need to be on the same CDN. If https://unpkg.com/browse/twemoji@14.0.2/ uses cloudflare url.

Here is an alternative CDN for twemojis: https://cdnjs.cloudflare.com/ajax/libs/twemoji/14.0.2/72x72/1f1e6-1f1fd.png

There is alternative CDNs, for example: https://unpkg.com/browse/twemoji@14.0.2/ The problem right now is that it doesn’t ship the icons and MaxCDN is basically hardcoded:

This project seems to be dead (last commit in April 2022) and probably no new features will be added in the future. I thought all the core maintainers of Twemoji were laid off, so why exactly do you need the organization?

I would love to hand it over if Twemoji was actively maintained again, but I don’t see a reason for a transfer right now, sorry.

That’s exactly it: the old maintainers of Twemoji are making a fork so it is actively maintained again, because we don’t want to see it die. We don’t want to publish to the original Twemoji package on NPM for legal reasons (we could theoretically get in trouble even if we have the right permissions). The organization would be used to house the fork for the community, not in a corporate way for Twitter or anything.

Also, as a suggestion regarding this issue:

You should give jsdelivr a try, they tend to have better loading times compared to unpkg/cdnjs.

This is exactly what we’re doing in the fork, which is currently waiting at https://github.com/jdecked/twemoji to be published.

Why not call the fork something different? Twemoji isn’t some corporate name developed by a marketing team. It came from the people who worked on it, so that’s why it has special meaning. Also, the style will be the same, so giving it the same name makes it easier to find for the sake of continuity.

Alright, we’re almost there: the last piece is that it seems that @unvented created an NPM organization by the name of “twemoji” already, so I can’t publish under the @twemoji namespace. It seems like the organization has only one package, last published over a year ago, and that future publishes for that package went under the “twemazing” org.

Samuel – would you mind giving up the twemoji org on NPM to keep things going here? 🙏

This project seems to be dead (last commit in April 2022) and probably no new features will be added in the future. I thought all the core maintainers of Twemoji were laid off, so why exactly do you need the organization?

I would love to hand it over if Twemoji was actively maintained again, but I don’t see a reason for a transfer right now, sorry.

Also, as a suggestion regarding this issue:

You should give jsdelivr a try, they tend to have better loading times compared to unpkg/cdnjs.

~ Cheers

The problem with the base solution is that if you are using typescript, it will not accept base in the options, I believe.

Other replies to this are right–the problem was in my own typescript definitions.

Hello World 👋

the fix you are all suggesting is in the README and it’s been there since day zero.

There is a base option documented (probably not superbly) which goal is to let you define any CDN you like as URL for emoji, or even your localhost.

I’ve already said that’s the right way to go but apparently there’s some issue in communicating that better than my tweet, this issue itself, or the README.

Maybe somebody should edit the top post to point at the base solution, as that was meant to be working since day zero in here, but apparently many never noticed the feature?

edit never mind I’ve just updated the OP comment.

Consider switching to jsDelivr https://www.jsdelivr.com/package/npm/twemoji We also host Bootstrap CDN.

The problem is the images/svg still point to maxcdn.com. Those images are not on jsdeliver.

The problem is that the assets are down (the actual emoji images), which causes issues with rendering and blocks the site loading. I suggest using this: https://github.com/jdecked/twemoji - I tested it and it works perfectly well. Also, @jdecked, who worked on the original script, is actively developing it! In my opinion this project here should be put to rest and the first sentence of the description should link to https://github.com/jdecked/twemoji. This would be the best solution for everybody.

@jdecked do we need to also add the definitelyTyped files for the new @twemoji/parser lib? And also shouldn’t we update this naming to match the new module name? https://github.com/jdecked/twemoji/blob/main/index.d.ts#L93

Otherwise we don’t get typescript support I guess?

Twemoji Parser has never had native TypeScript support. Feel free to PR types if you want them; I’m largely uninterested in maintaining types for either of these libraries given I’m not a TS user, but just as before I’ll continue to accept PRs contributing TS types from people who want them.

Good catch on the naming for the Twemoji TS module. Since it worked before, I’ll update the naming next week as I’m currently travelling – or someone is free to PR, which I can merge from my phone. 😃

@jdecked do we need to also add the definitelyTyped files for the new @twemoji/parser lib? And also shouldn’t we update this naming to match the new module name? https://github.com/jdecked/twemoji/blob/main/index.d.ts#L93

Otherwise we don’t get typescript support I guess?

This issue has been fixed through a fork and the new module is called @twemoji/api and it’s already available on npm.

I am closing this issue as no more work will be done in this repository around this library, or better … nobody that doesn’t work @ Twitter would likely do anything in here to change the current state.

Use an explicit base options’ field, as specified in the README, if you don’t want to switch to the current fork, or just switch to the fork which is being maintained by people that care about this project 👋

Thanks @unvented and thanks @jdecked for the follow up 🍻

@jdecked also, why give Twitter the pleasure by naming the fork after it? Give the library a new name and make it a standalone open source project!

@WebReflection That’s how I fixed it 🙃

Mozilla provides builds of Twemoji as regular font here, might be a useful alternative to the JS library: https://github.com/mozilla/twemoji-colr/releases

Hi @WebReflection, Dose this patch fix also build older version of twemoji? (eg. version 2 in https://unpkg.com/twemoji@2.2.2/dist/twemoji.min.js)

@yhatt yes, the library is meant to run even on localhost, so that changing the base field should always work (it does on my machine 😅) however, the default is a broken CDN, and I think this should be fixed.

I don’t think I can deploy to npm but if @jdecked somehow has issues in porting master/dist to gh-pages branch and publish from it, which is basically what deploy.sh does, I can try and eventually fail at publishing time.

@jdecked I believe what’s next, as I’ve merged into master the CDN change, is to actually run npm run deploy or basically bring the dist folder into gh-pages branch, and then publish from there to npm … this should just bring in latest .js files with the different CDN, and upload the new package that should work out of the box. Dare I say, as this is currently fully broken for everyone, a patch version might be what everyone would hope for, but then again, history told us sneaky patches are bad, so at least a minor, if not a major, would be needed, imho … but I let you decide on that.

If someone who controls the domain is reading then please get in contact cause we can provide a custom CDN to get all sites back online