bundle.run errors breaking notebooks

1

My notebooks often need bundle.run to load npm libs, as officially recommended for stubborn modules. But lately, the service has been failing, causing my notebooks to break.

For example, all of these are down at the moment:

For the short term, I’ve reported a packd issue.

For the longer term, I wonder if it makes sense for Observable to offer an endpoint to cache and serve modules loaded from bundle.run, since they seem pretty important to keeping our notebooks stable.

1 Like
2

The issue seems to be fixed now. I’m not sure what causes bundle.run to fail intermittently like this.

Let me know if Observable caching UMD-converted modules from bundle.run or others for notebook stability seems reasonable.

3

Yep, it’s been a bummer that bundle.run isn’t 100% stable. We’re weighing different options, including hosting an instance, re-caching, or just trying to contribute where we see bugfixes. As it stands, there unfortunately is only so much good that immutable caching can do, given that bundle.run often fails to build packages.

2 Likes
4

Yesterday https://wzrd.in was also down all day.

1 Like
5

hah! it’s days like that I wish more folks moved to proper es6 modules and hosted them on unpkg.com :wink:

6

It’s been down for 3 days now, probably was down prior to when I noticed, but I was relying on wzrd.in a couple weeks ago. There is some problem in that they are not serving https back properly. Any ideas on who to contact or how to nudge them to get back online properly?

7

advice is to use http://bundle.run instead (which seems more reliable, albeit still has problems).

you can report wzrd.in issues here: https://github.com/browserify/wzrd.in/issues

1 Like
8

Hey thanks! bundle.run worked, will ping the wzrd folks as well.

9

While we’re on the topic—I just now tried a few libraries related to unit conversion that I needed, and all of them required bundle.run to work.

Of course it’s not that simple to have require “just work” for everything, but I’m starting to wonder if require("foo@1.2.3") should or could be made to automatically fall back to something like bundle.run or a reliable cache thereof.

10

For the record, I ran into the same problem at the end of May: https://github.com/Rich-Harris/packd/issues/49

11

I am having the same problem today (September 9th) - a module that worked yesterday (xml2js) does not work anymore…

12

same problem today, but wzrd.in worked.

1 Like
13

What is the current best practice?

I have been told the recommendation is to download the JS module, ie. https://bundle.run/node-matrices@1.0.0, then attach the file to the notebook, and finally require the attached module, replacing

Matrix = require('https://bundle.run/node-matrices@1.0.0')

by

Matrix = require(await FileAttachment("node-matrices-1.0.0.js").url())

Is it correct? Is there a preferred alternative?

3 Likes
14

One workaround that helped me to circumvent cached broken builds was to attach a cachebreaking param to the URL, e.g. https://bundle.run/node-matrices@1.0.0?cb123. I imagine this could be automated to some degree and integrated into a require wrapper.

1 Like
15

Can the cachebreaking exhaust bundle.run storage space? Looks like it is unable to process new packages.

16

Yes, it would appear that each hash considers the full query. A static cachebreaker should be fine, but with a dynamic one (like timestamps) you’d likely be spamming bundle.run.

1 Like