quarto-dev / quarto-cli

Open-source scientific and technical publishing system built on Pandoc.
https://quarto.org
Other
3.99k stars 328 forks source link

Documents using Observable JS are not self-contained #1412

Open arbelt opened 2 years ago

arbelt commented 2 years ago

Observable JS doesn't seem to work without network connectivity because dependencies are pulled in at runtime (e.g., htl).

Haven't explored this in depth, but it seems that for recommended libraries like Inputs, I can download a local copy and require from an OJS chunk (since these get inlined?). But this doesn't work with htl, which might be needed earlier by the runtime. If this is complicated, perhaps there could be an option to include a "heavyweight" stdlib with all dependencies bundled (regardless of whether they're used or not) in the short-term?

More generally, it'd be nice if all JS/Observable dependencies were inlined for a self-contained document, rather than just the local ones... it seems this can be worked around by fetching local copies, but it's a bit cumbersome, and automating it behind the scenes would make code a little more immediately portable between QbservableHQ and Quarto.

I'm running Quarto 1.0.23.

Thanks so much for the awesome work and creating this amazing tool!

arbelt commented 2 years ago

Correction: import from a local ES module correctly inlines the module. For require on a local file it was still resolving at runtime. But Inputs = require(await FileAttachment("path/to/local/inputs.min.js").url()) seems to work...

cscheid commented 2 years ago

We're glad it's useful for you! We hear you wrt self-contained and we would like to do something about it in the future. However, it's a significant undertaking because the observable runtime has web dependencies fairly deep in their codebase, through their d3-require dependency, so we have no concrete plans to share yet.

victorfeagins commented 1 year ago

Just a comment here to say I am also interested in this. I like to create presentations with Revealjs and having a single html file to share is nice to have and sometimes necessary.

declann commented 1 year ago

+1 for flexibility around runtime dependency sourcing, but for privacy and compliance, performance, network and reliability implications.

Here is a manual workaround I'm using for my website:

  1. I host a mirror of CDN resources, see https://gitlab.com/declann/calcwithdec.dev/-/tree/main/_site/resources_vz/mirrors It's an empirical list that I update through testing (some of the scripts I use are also available here).

  2. In _site quarto-ojs-runtime.js L256 I change the jsdelivr reference to point to my resources_vz/mirrors location above.

  3. I comment 2x remote math resources that I don't need in a page that uses the listings feature: https://gitlab.com/declann/calcwithdec.dev/-/blob/main/_site/index.html#L102 (discussion link)

I need to maintain these allowances every time I render for deploy, since quarto generates new files. And I need to test manually, in particular since this is clearly not a robust process.

quarto-ojs-runtime.js includes a reference to https://cdn.observableusercontent.com/npm/ that is definitely used to load from OHQ notebooks, but since I currently don't do that on my website I don't update/maintain that update.

cscheid commented 1 year ago

Just to be clear, we 100% agree on the desirability of the feature. It's simply that we our plates are full for the foreseeable future, and we don't think we can deliver a sufficiently robust solution.