ga.jspm.io: new URLs are 404

[trusktr]

I'm getting 404s for these:

import('https://ga.jspm.io/npm:three@0.155.0/').then(console.log) // 404
import('https://ga.jspm.io/npm:lume@0.3.0-alpha.30/').then(console.log) // 404
import('https://ga.jspm.io/npm:lume@0.3.0-alpha.30/dist/index.js').then(console.log) // 404

This is not 404:

import('https://ga.jspm.io/npm:lume@0.3.0-alpha.28/dist/index.js').then(console.log) // ok

If you take this working playground example and update it to this, it breaks because of the 404s.

[trusktr]

The generator is also unable to generate import maps for new versions of packages:

https://generator.jspm.io/#U2NgYGBkDM0rySzJSU1hyCnNTXUw0DPWM9BNzCnISNQzNgAARIM29iIA

failing with something like "unable to load configuration".

[trusktr]

After a few minutes, it started working for https://ga.jspm.io/npm:lume@0.3.0-alpha.30/dist/index.js

I just tried https://ga.jspm.io/npm:lume@0.3.0-alpha.29/dist/index.js and it is 404.

Looks like something in the CDN is flaky right now.

[guybedford]

New package publishes can sometimes take a while to appear on JSPM. This is the area of the most development on the CDN at the moment, and we are introducing updates all the time. You can initiate a build queue request from the API and that should usually update the builds fairly quickly. This problem of new packages taking a while will get resolved eventually with the next architecture under development.

[trusktr]

Ah ok. I figured that the CDN would keep the request alive while building the package on first access. It seems that this is what other CDNs do, and so the first request to a package takes longer than subsequent requests, but at least doesn't fail. Is that being looked into? I Imagine it very useful because then we can push updates to users without having to wait for packages to exist; just push and refresh user's apps (one unlucky user might get a slow reload, or we can also ensure our CI is the first user to hit new URLs).

[guybedford]

To give a brief architecture summary - yes this is exactly how the project was first implemented as an on-demand build application. But then it was built for scale using a build queue system. The build queue has also undergone a bunch of rearchitecting internally. Reintegrating on-demand loads with the build queue is in theory a simple thing to do, and is very much a goal. Development time is going primarily into optimization and cost reduction right now though as the major goal to ensure sustainability of the project. But on-demand loads will happen eventually.