Updatte codeblock-to-json.ts to match new Quarto behaviour

[kv9898]

Also at quarto-ext/shinylive#65

In the current implementation, codeblock-to-json.ts uses:

import { readLines } from "https://deno.land/std/io/mod.ts";

Quarto 1.6 introduced breaking changes, which require an update in the code in favour of sth like:

import { readLines } from "stdlib/io";

[georgestagg]

As mentioned in the linked thread, this will require some thought to handle both the breaking change in Quarto and older versions. We might require two scripts and use the correct one based on quarto version.

[georgestagg]

My understanding is that this should now be working again in the latest Quarto builds.

We should leave this open for the moment, however, since it's possible Quarto might re-enable the use of --cached-only in the future and if so our script will break again.

[gadenbuie]

Should this have been fixed in Quarto v1.6.40? I tried to upgrade my blog from Quarto v1.5.57 to v1.6.40 and am hitting this error with the latest shinylive:

shinylive::assets_info()
#> shinylive R package version: 0.3.0.9000
#> shinylive web assets version: 0.9.1

[cderv]

Yes it should have as the old scheme seemed to work with the change we made... 🤔

Let me check, as otherwise I'll do the initial fix we discussed.

[gadenbuie]

@cderv Do you know where the packages downloaded by deno should be stored? I'm only able to reproduce this issue on my personal machine, but I can render the site on a different machine. I can't find any meaningful differences between the environments. Any ideas or pointers?

[cderv]

You could have some cache problem while using multiple versions across time.
This command will give you various path used by deno

deno info

Removing full DENO_DIR could help start fresh.

Deno 2 move library to https://jsr.io/ and this created some problem with earlier deno version and how we try to bundle.

[gadenbuie]

That's what I thought too, but I've tried that and I get the same result

❯ ~/.local/share/qvm/versions/v1.6.40/bin/tools/aarch64/deno info
DENO_DIR location: /Users/garrick/Library/Caches/deno
Remote modules cache: /Users/garrick/Library/Caches/deno/deps
npm modules cache: /Users/garrick/Library/Caches/deno/npm
Emitted modules cache: /Users/garrick/Library/Caches/deno/gen
Language server registries cache: /Users/garrick/Library/Caches/deno/registries
Origin storage: /Users/garrick/Library/Caches/deno/location_data

❯ ~/.local/share/qvm/versions/v1.6.40/bin/tools/aarch64/deno clean
❯ rm -r ~/Library/Caches/deno

Also, I don't have system deno

❯ which deno
deno not found

[gadenbuie]

Thanks to @cderv's help in asking the right questions, I realized this is happening for me for two reasons:

1. I was using v0.1.0 of the shinylive quarto extension. If you're experiencing something similar, I'd recommend updating: quarto add quarto-ext/shinylive.

2. I was using qvm to render my blog with Quarto v1.6.40, but I still had quarto v1.5.55 installed globally. The 0.1.0 version of shinylive wasn't using the same quarto binary as the render process due to feat(lua): When possible, use Quarto Lua API from Quarto 1.5.32+ to get the path to quarto quarto-ext/shinylive#51. This is why no amount of changing the version used to render my blog would affect the error message.