One of the frontend libraries, https://unpkg.com/[email protected]/js/jquery.guillotine.min.js, can't be accessed from the build environment, causing our recent streak of AppVeyor build failures. It looks like a bug in unpkg: https://github.com/unpkg/express-unpkg/issues/70
This bug has the potential to affect all our users based in the same geographical location as the AppVeyor servers (seems to be U.S. based on their build environment IP). The effect for now is small (unable to edit profile pictures using the web UI), but it does raise the question of whether we've become over-reliant on CDNs (or rather, a single CDN) since #6346 (#6373).
Possible fix: failover to local copy?
Good work in following up with unpkg guys @whipermr5 馃憤
Now that we have Webpack, we can consider using it to bundle all the necessary dependencies. That way, we get the best of both worlds:
node_modules, so does not count as hosting locally)Although with a minor upset: adding a new library (if necessary) will not be as simple as before. Need to make sure that the new library works well with Webpack.
Happened again on the qunit library on Travis, but it's enough to fail builds now (check all the builds from 9080 until the time of writing, they all fail on AllJsTests. I can submit a quick fix for the current setback, but perhaps we really need to consider Webpacking everything in order to prevent this problem for good.
It has struck again, this time for bootstrap, making it a major issue: https://github.com/unpkg/unpkg-website/issues/41#issuecomment-322737546
Instead of unpkg.com we can use this:
https://npm-cdn.herokuapp.com/{packageName}@{packageVersion}/{filePath}
I know this is not one of the best ways to resolve this error, but until the time we are looking for a better solution, we can use this. Everything looks good to me :+1:
And this won't require much change, just the base URL needs to be changed.
https://unpkg.com TO https://npm-cdn.herokuapp.com
@amarlearning thanks for your input; we are already switching to jsDelivr in live site and master branch should follow soon. Besides, "the entire package tarball has to be fetched" and "It's running on a single Heroku dyno so it won't scale. To become a real thing it will need to sit behind a CDN." look like good reasons not to use npm-cdn.
On that topic, @whipermr5 if jsDelivr is as reliable as they claim to be, it looks like I can just discontinue my PR?
@wkurniawan07 The datamaps aren't available in jsDelivr though. I still like the idea of webpacking everything.
https://teammatesv4.appspot.com/usermap.jsp is giving errors due to the issue that @whipermr5, maybe open a separate issue to fix that?
@amarlearning I would highly recommend against using npm-cdn, the reason being:
This is a proof of concept app. It works, but it's experimental. It's running on a single Heroku dyno so it won't scale. To become a real thing it will need to sit behind a CDN.
Edit: Didn't see the comment by wilson above, he already covered some of the reasons.
Resolved in V7.
Most helpful comment
@amarlearning I would highly recommend against using
npm-cdn, the reason being:Edit: Didn't see the comment by wilson above, he already covered some of the reasons.