Support VitePress (Vite/Vue SSG)

[birkskyum]

VitePress - Website - GitHub

Platform

Darwin 22.6.0 arm64 arm

Version

deno 1.37.0

Repro

• create a new folder and cd to it
• deno run -A npm:vitepress init - just step through
• deno run -A npm:vitepress dev - Dev mode is working 🎉
• deno run -A npm:vitepress build

Expected

That a build is made

Actual

➜ deno task build
Warning Currently only basic package.json `scripts` are supported. Programs like `rimraf` or `cross-env` will not work correctly. This will be fixed in an upcoming release.
Task build vitepress build docs
vitepress v1.0.0-alpha.28
✓ building client + server bundles...
build error:
 TypeError: Cannot read properties of undefined (reading 'hash')
    at file:///Users/admin/repos/deno-kitchensink/vitepress-project/docs/.vitepress/.temp/app.js:369:42

[littledivy]

vitepress is trying to access location.hash. If I run the build script using deno run --location http://example.com, it works.

[bartlomieju]

#20339 (comment)

[birkskyum]

With deno 1.40 the build now errors at:

➜ deno run -A npm:vitepress build

  vitepress v1.0.0-rc.40

build error:
TypeError: unknown variant `junction`, expected `file` or `dir`
    at Object.symlinkSync (ext:deno_fs/30_fs.js:545:3)
    at Object.symlinkSync (ext:deno_node/_fs/_fs_symlink.ts:21:8)
    at Object.createSymlinkSync$1 (file:///Users/admin/repos/deno-kitchensink/new-vitepress/node_modules/.deno/[email protected]/node_modules/vitepress/dist/node/serve-e9-zRdpq.js:2160:27)
    at linkVue (file:///Users/admin/repos/deno-kitchensink/new-vitepress/node_modules/.deno/[email protected]/node_modules/vitepress/dist/node/serve-e9-zRdpq.js:46718:12)
    at build (file:///Users/admin/repos/deno-kitchensink/new-vitepress/node_modules/.deno/[email protected]/node_modules/vitepress/dist/node/serve-e9-zRdpq.js:46622:21)
    at eventLoopTick (ext:core/01_core.js:59:7)

Also, in the dev mode (deno run -A npm:vitepress dev) I see Deno.stdin deprecation warnings now, but vitepress isn't a deno-specific package and i doubt it uses Deno.stdin.rid anywhere.

➜ deno run -A npm:vitepress dev  

  vitepress v1.0.0-rc.40

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h to show help
warning: Use of deprecated "Deno.stdin.rid" API. This API will be removed in Deno 2.

hint: Use `Deno.stdin` instance methods instead.

[birkskyum]

@littledivy , i upgraded to latest canary, and when i run the build command now i see:

➜ deno run -A npm:[email protected] build

  vitepress v1.0.0-rc.45

✓ building client + server bundles...
build error:
TypeError: Relative import path "vue/server-renderer" not prefixed with / or ./ or ../
    at file:///Users/admin/repos/deno-kitchensink/vitepress-working/.vitepress/.temp/app.js?t=1709976732378:2:161
    at async build (file:///Users/admin/repos/deno-kitchensink/vitepress-working/node_modules/.deno/[email protected]/node_modules/vitepress/dist/node/serve-CXeFQMGg.js:46677:24)

[birkskyum]

Can this be re-opened?

[littledivy]

Hmm, does it work using BYONM?

// deno.jsonc
{ unstable: ["byonm"] }

$ npm i vitepress
$ deno task docs:build

[birkskyum]

Oh right, I missed that - where will these details for each framework be stored? Could there be a frameworks section somewhere in the deno docs?

It actually did fix build, but the preview break with this when I go to the localhost:

➜ deno task docs:preview
Task docs:preview vitepress preview

  vitepress v1.0.0-rc.45

Built site served at http://localhost:4173/
error: Uncaught (in promise) TypeError: Cannot set properties of undefined (setting 'statusCode')
    at Polka.onError (file:///Users/admin/repos/deno-kitchensink/vitepress-working/node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/vitepress/dist/node/serve-CXeFQMGg.js:63027:24)
    at next (file:///Users/admin/repos/deno-kitchensink/vitepress-working/node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/vitepress/dist/node/serve-CXeFQMGg.js:63103:38)
    at eventLoopTick (ext:core/01_core.js:208:9)

[littledivy]

where will these details for each framework be stored? Could there be a frameworks section somewhere in the deno docs?

We still need to figure out a good DX for this. Ideally the user wouldn't have to know about 'byonm'

[KnorpelSenf]

IMO it would be great if Vitepress could be supported without a node_modules folder. Would this require any changes to Vitepress?

[marvinhagemeister]

Tried to reproduce the issue again and it seems like the mentioned problems have been resolved. I'm now stuck on the following error:

TypeError: Relative import path "vue/server-renderer" not prefixed with / or ./ or ../
    at file:///<project>/.vitepress/.temp/app.js?t=1712960529044:2:161
    at async build (file:///<project>/node_modules/.deno/[email protected]/node_modules/vitepress/dist/node/serve-Csn-CKFx.js:46758:24)

[littledivy]

@marvinhagemeister It works with npm i with DENO_FUTURE=1. Removing the node resolution tag.

[littledivy]

Closing, all functionality is working with DENO_FUTURE=1. DX will get better when deno i is added

$ deno run -A npm:vitepress init
$ npm i vitepress
$ export DENO_FUTURE=1

$ deno task docs:dev
$ deno task docs:build
$ deno task docs:preview

[alexgleason]

I was able to get Vitepress building without node on Deno v1.45.5, but I hit a few obstacles: #24916, vueuse/vue-demi#266, denoland/deno_docker#386

This works:

export DENO_FUTURE=1

deno i --allow-scripts=npm:esbuild
deno task build

The esbuild postinstall is needed, but if you just use --allow-scripts without any arguments, vue-demi will throw an error in its postinstall. So it needs to be skipped.

For me, git was also needed on my system.

[marvinhagemeister]

@alexgleason Can you open a new issue for that? It sounds like the issue is different from what the original poster here ran into, even if both happened in the context of vitepress. Tracking issues separately makes it much easier for us to handle them.

[alexgleason]

@marvinhagemeister I opened #24916, just wanted to update this thread as well for posterity.

[marvinhagemeister]

@alexgleason Sweet, thanks for opening a new issue. Instead of commenting on closed issues, you can link your issue to the old one by adding something in your text like:

Relates to: <LINK TO THE ISSUE>

By putting a link to another issue in your issue GitHub will automatically create a shared connection that is visible from both issues. That's an easier way to update other issues without having to create new comments there.