# Is ?v=3 correct when requesting notebook js? **URL:** \ **Category:** Help\ **Created:** [May 12, 2019, 10:37pm UTC](https://talk.observablehq.com/t/is-v-3-correct-when-requesting-notebook-js/1971 "2019-05-12T22:37:35Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![rreusser](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/rreusser/32/1976_2.png) [@rreusser](https://talk.observablehq.com/u/rreusser)\ **Post date:** [May 12, 2019, 10:37pm UTC](https://talk.observablehq.com/t/is-v-3-correct-when-requesting-notebook-js/1971/1 "2019-05-12T22:37:35Z")
Hi! My goal is to get a notebook running on a static webpage. I’ve been poking around, but I’m wondering if I can confirm a thing or two about the observable runtime. While working through [the runtime example](https://github.com/observablehq/runtime#observablehqruntime) I made the mistake of removing `?v=3` from a request to [https://api.observablehq.com/@tmcw/hello-world.js?v=3](https://api.observablehq.com/@tmcw/hello-world.js?v=3), having mistakenly thought maybe `v` corresponded to the runtime version. Am I correct in understanding: - `?v=1`: returns a deprecated notebook format (requires `runtime.load()`?) - `?v=3`: returns the currently preferred format - `?[blank]`: equivalent to `?v=1` Long story short, is it correct to use runtime v4 along with `?v=3`? ---
**Author:** ![mbostock](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/mbostock/32/9_2.png) [@mbostock](https://talk.observablehq.com/u/mbostock)\ **Post date:** [May 12, 2019, 10:49pm UTC](https://talk.observablehq.com/t/is-v-3-correct-when-requesting-notebook-js/1971/2 "2019-05-12T22:49:29Z")
Yep! Use the `v=3` format with the latest version of the runtime. Sorry for the confusion—we are in a slightly awkward spot where we haven’t quite finished the migration to the new format. ---
**Author:** ![rreusser](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/rreusser/32/1976_2.png) [@rreusser](https://talk.observablehq.com/u/rreusser)\ **Post date:** [May 19, 2019, 12:49am UTC](https://talk.observablehq.com/t/is-v-3-correct-when-requesting-notebook-js/1971/3 "2019-05-19T00:49:43Z")
Just curious: do you plan to keep v1 API support for the foreseeable future? Just debating whether to build on it (it’s a bit easier at the moment) or whether to figure out v3 now to prevent breakage. Thanks! ---
**Author:** ![mbostock](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/mbostock/32/9_2.png) [@mbostock](https://talk.observablehq.com/u/mbostock)\ **Post date:** [May 19, 2019, 5:59am UTC](https://talk.observablehq.com/t/is-v-3-correct-when-requesting-notebook-js/1971/4 "2019-05-19T05:59:23Z")
It’ll keep working for the foreseeable future, but we’d love to understand your use case better. What makes v1 easier for you? ---
**Author:** ![thadk](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/thadk/32/251_2.png) [@thadk](https://talk.observablehq.com/u/thadk)\ **Post date:** [May 22, 2019, 7:04am UTC](https://talk.observablehq.com/t/is-v-3-correct-when-requesting-notebook-js/1971/5 "2019-05-22T07:04:40Z")
Sorry to jump in here on this thread with a similar issue for v1 versus v3 runtime API troubleshooting. Much gratitude for implementing v3 for tgz! Granted our collaborative notebook is excessively sprawling, but I would welcome any tips on how to mitigate `Uncaught RangeError: Maximum call stack size exceeded` so e.g. `d3` and/or `barRangeSlider` can load in an untarballed localhost-hosted v3 version of this notebook: [https://observablehq.com/@thadk/windfall-awareness-notebook-prototype](https://observablehq.com/@thadk/windfall-awareness-notebook-prototype) (really, I think this holds the issue: [https://observablehq.com/@bumbeishvili/data-driven-range-sliders](https://observablehq.com/@bumbeishvili/data-driven-range-sliders) ) I will soon try using NPM again with the v3 tgz, which is our main use for the tarball. Still, it was comforting (if not necessarily essential) with v1 to see even index.html unhosted (file://) html load the full notebook when uncompressed in both Firefox, Safari and Chrome. Now, running a server is required and only works in Safari/Chrome yet. After further testing, it seems like `barRangeSlider` is using up the call stack in a different order in v3 than it was in v1 (though that part also didn’t work in v1 of the independent runtime). If I edit the v3 .js and pull d3, fastxml, and form above that, no problem: ```auto const child1 = runtime.module(define1); main.variable(observer("fastXml")).define("fastXml", ["require"], function(require){return( require('https://bundle.run/fast-xml-parser@3.12.16') )}); main.variable(observer("d3")).define("d3", ["require"], function(require){return( require("d3@5") )}); const child5 = runtime.module(define5); main.import("form", child5); main.import("table", child1); const child2 = runtime.module(define2); main.import("select", child2); main.import("textarea", child2); main.import("file", child2); main.import("input", child2); main.import("slider", child2); main.import("date", child2); main.import("radio", child2); main.import("checkbox", child2); main.import("number", child2); const child3 = runtime.module(define3); main.import("NumberParser", child3); const child4 = runtime.module(define4); main.import("barRangeSlider", child4); ``` ---
**Author:** ![mbostock](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/mbostock/32/9_2.png) [@mbostock](https://talk.observablehq.com/u/mbostock)\ **Post date:** [May 22, 2019, 5:25pm UTC](https://talk.observablehq.com/t/is-v-3-correct-when-requesting-notebook-js/1971/6 "2019-05-22T17:25:54Z")
This has been fixed in release 4.2.1 of the Observable runtime (which should be live in tarball downloads in a few minutes). Thanks for the report! ---
**Author:** ![rreusser](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/rreusser/32/1976_2.png) [@rreusser](https://talk.observablehq.com/u/rreusser)\ **Post date:** [July 25, 2019, 6:43pm UTC](https://talk.observablehq.com/t/is-v-3-correct-when-requesting-notebook-js/1971/7 "2019-07-25T18:43:35Z")
Sorry for such a delayed response! In short, if I recall correctly, v1 bundles imported code with the notebook where v3 relies on `import` to resolve it. I’ve dragged my feet for a long time about embracing yield, generators, import, and ES6 in general, but I’m making an effort to get on board with it. The particular use-case was for downloading, caching, and exposing notebook cells in an [idyll](https://idyll-lang.org/) document. Since the code may get bundled with non-import-aware tools, I think external imports means doing some of that resolution ourselves instead of being able to get away with having everything simply available from a single fetch. So in that sense it’s just a convenient side effect that makes things a bit easier to process. Do correct me if I’m mistaken about any of this though. Like I said, I have a bit of a loose grasp of the specific details of `import` support—both implications and current status in different environments. ---
**Author:** ![mbostock](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/mbostock/32/9_2.png) [@mbostock](https://talk.observablehq.com/u/mbostock)\ **Post date:** [July 25, 2019, 7:36pm UTC](https://talk.observablehq.com/t/is-v-3-correct-when-requesting-notebook-js/1971/8 "2019-07-25T19:36:52Z")
Even with v=3, you’ll get the complete code (meaning including all transitive notebook dependencies) when you download the tarball. So I’d use that instead of the .js endpoint if you want to download everything.