Unpkg.com behaving badly

[scalaris]

For those of you using tagify component, your users are probably experiencing page loading delays today - unpkg.com is barely serving data.

This really needs a solution

[Teodor]

I am experiencing no issues with unpkg today, testing some stuff on pages using tagify - server response time for the tagify js file is like 12ms and content download about 0.4ms.

[scalaris]

I’m seeing intermittent lag. 39 second load times

[Mr.Rubi]

Right now I’m trying to solve this problem. A large number of complaints from users. After testing, I found out that the problem is in unpkg and it is in the tagify component, because all the other components that I use are hosted locally. It looks like you will have to urgently edit the code and rebuild the application manually without using a Wappler.

The ability to install the component locally would save many problems.

[sitestreet]

I’ve had issues on and off with Tagify because of the unpkg hosting of the scripts. Having them stored locally and then update through the normal Wappler updates would be a much better solution.

[tbvgl]

I’m storing them locally because of that as well. unpkg.com is very unreliable.

[scalaris]

Any issues doing so? Simply a case of copying a few files to a local server?

[tbvgl]

Yeah, add the scripts from the CDN to your server. Wappler will overwrite your custom source, though. You can prevent that with a workaround. Wappler checks the script source but not the type so that you can add Wapplers version as application/json and yours as the script.

Here is an example:

# your local script
 <script src="pathToYourScript" defer=""></script>

#Stylesheet
  <link rel="stylesheet" href="https://unpkg.com/@yaireo/tagify/dist/tagify.css" />

#dmx connect
  <script src="/dmxAppConnect/dmxTagify/dmxTagify.js" defer=""></script>

#workaround to prevent Wappler from overwriting your script
  <script type="application/json" src="http://unpkg.com/@yaireo/tagify" defer></script>

[tbvgl]

@Teodor Just a suggestion but that might be an easy fix for you guys. If you want to stick to CDNs or allow local script then you could add a fallback so that we can load a local script or you fall back to their other CDN if unpkg.com is not available:

So instead of:

<script src="http://unpkg.com/@yaireo/tagify" defer></script>

you could do:

<script src="http://unpkg.com/@yaireo/tagify" onerror="this.onerror=null;this.src='https://cdn.jsdelivr.net/npm/@yaireo/tagify';" defer></script>

[JonL]

Jsdelivr is way more reliable than unpkg. It has better infra and has fallbacks. I use it for all my external libraries.

[scalaris]

Thanks Jon,

Can you share the include code to replace the default unpkg one - I will update everything right now if you do.

And thanks again.

[JonL]

You have a converter here:

Migrate from unpkg to jsDelivr

Paste the unpkg url and get the jsdelivr one.

0 outages last year.

[scalaris]

Thanks - does wappler play well with it ?

[tbvgl]

It’s the same scripts hosted on unpkg. You don’t even need a converter because Tagify already has their stuff on jsdelivr.

[JonL]

The only problem is that Wappler will try to re-add your unpkg links if you are using an AC component that makes use of certain library. Like tagify.

It’s a nuisance to remove them but once you have committed a version with the jsdelivr url and not with unpkg it’s just a matter of discarding the line until an alternative is provided.

[tbvgl]

you can do this to prevent wappler from readding the script Unpkg.com behaving badly

[scalaris]

Thank you both.

Top class

[tbvgl]

So tagify on unpkg keeps going down for hours now. We really need a solution to this.