Embedding specific version

Community Help
1

Hi! Looks like referencing specific version of the notebook when doing npm install https... does not work as per this documentation:

The docs advise appending @versionNumber before the file extension, however, this returns 404.

Is there any way to lock the embedded version?

Thanks so much for all your good work!

-Albert

2

We currently donā€™t support version pinning for notebooks that have not been published. Weā€™ll fix thatā€”thatā€™s a bug.

If you did publish your notebook, perhaps you are specifying a version that wasnā€™t published or shared? You can only pin to versions that are published or shared. The available version numbers arenā€™t currently exposed in the user interface anywhere (sorry about thatā€”weā€™re working on a history feature). But you can see the latest published or shared version by clicking ā€œDownload Codeā€ in the notebook menu.

For example, hereā€™s a test notebook:

Hereā€™s the unversioned link to the code:

https://api.observablehq.com/@mbostock/hello-code.js?key=f50c5ec39a1d51d1

As you can see from the unversioned link, the current version is 12, so hereā€™s a link pinned to that version:

https://api.observablehq.com/@mbostock/hello-code@12.js?key=f50c5ec39a1d51d1

2 Likes
3

Yep, in my case Iā€™m working with an unpublished notebook indeed (although shared). I copied the tarball link and was hoping to add it to our code as an npm dependency. Exact versioning is crucial in this use case because yarn expects the same output to be returned on each install.

Solution:

Looks like this is now working (not sure if this changed since my posting):

yarn add https://api.observablehq.com/d/a7b2ff0028da5df6@939.tgz?key=b7fee01aeb212912

So basically taking the tarball URL of the unpublished notebook and adding a version number before the extension. When used together with key attribute, this seems to return the version specified! :ok_hand::clap:

1 Like
4

For some reason thereā€™s still an problem with the same version resulting in a different hash for different users / on different days. Yarn complains:

Fetch succeeded for undefined. However, extracting "https://api.observablehq.com/d/...@939.tgz" resulted in hash "8b7f957853fd67d1139ef4d5ec08f5f39bf6b5a2", which did not match the requested hash "413e88a9c34249819555ee8e941c3757855be1bf".

Maybe something changes in the tarball due to some internal changes in Observable, which results in a slightly different output and hash even having the same version number. :grimacing:Not sure how to handle thisā€¦

-Albert

5

Suggestion for anyone whoā€™s facing this problem: download the tgz file from observablehq and host it yourself on any public static server - then use that URL as your npm dependency. :ok_hand: This way the output will always stay the same, regardless if observablehq changes the code or not.

1 Like
7

Iā€™m having the same problem over here. In my case I was getting the yarn error message about the hash mismatch when I would build the app for deployment to Google App Engine. I had my notebook @gabgrz/github-contributions fork listed as a dependency in the package.json file.

When I ran yarn install, yarn would add this entry in the yarn.lock file for my dependency:

"@gabgrz/github-contributions@https://api.observablehq.com/@gabgrz/github-contributions.tgz?v=3":
  version "452.0.0"
  resolved "https://api.observablehq.com/@gabgrz/github-contributions.tgz?v=3#2e5ad71a20c9eecf38078d45920d26592dfbcf1a"

Removing this entry, and executing the deployment command again made the build to be successful this time.