🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)

So the problem on Windows with the build is the following.

PS D:\a\quarto-cli\quarto-cli\src\webui\quarto-preview> ..\..\..\package\dist\bin\tools\x86_64\deno.exe task build
Task build tsc --noEmit && vite build
'deno' is not recognized as an internal or external command,
operable program or batch file.

Something calling deno task with our bundled deno is not enough, and somewhere deno is looked for in the PATH. However, it is not set.

The quick fix here is to add Deno.execPath() to the PATH for running deno task.

This is done only for Windows as it seems to be the problem. (I should probably have added a not in comment).

I did not find where running tsc --noEmit && vite build would call deno. So I really don't know why we encounter this. I can just confirm

• I can reproduce locally if I don't have deno in PATH
• Adding the commit helps and solves it locally

Ok so I really wanted to understand the problem and could really pinpoint the exact issue. However it seems to me that having deno in PATH is a requirement when deno task is ran.

However, it also means that using custom/path/deno.exe task build does not ensure that the same deno binary will be used, if this is another one in PATH.

I don't know why we need to use Deno for quarto-preview.js. It seems that this should be built independently using npm.

vite is also used in quarto-dev/quarto repo for several tools, and I wonder if this quarto-preview.js really needs to be rebuilt every time.

Anyhow, to solve this we need to have our bundle deno in PATH.

• I did it by adding to PATH when running deno task
• We could also be sure to add our bundled deno.exe to PATH at the very beginning of configure.sh or configure.cmd so that we know for sure that any call to deno will use this one.

we'll need to write vendor.cmd to go alongside package/scripts/vendoring/vendor.sh, because with Deno 2 we're using that at every call to configure, including when we (eventually) build installers

I added a script. It runs ok locally - I am not sure how to test locally to be 100% sure that we do not need to add some windows specificity. Right now, it does the exact same as vendor.sh

I don't know why we need to use Deno for quarto-preview.js. It seems that this should be built independently using npm.

I agree. I believe this was an old attempt by JJ back when Deno first announced "npm support", but it's not particularly important. We either move everything about that build step to Deno, or everything to node. It doesn't look like Deno's support is robust enough.

Ok, I'm going to merge this and then build (but not release) installers. I expect these won't work, but we can then debug.