vitepress do not work on host where the subpath is unknown

[wighawag]

Describe the bug

vitepress require user to set a specific base path (default to /) and do not work on host where the pathname where the website is fetched from is unknown

3 uses cases where this happen:

• ipfs or other content-addressable network where the pathname is a hash that cannot be known before build time
• archive website like the wayback machine that host website on sub path
• some website that let you embed other website but where you are not in control of the path

This works with svelte+kit and so I expect vite to support that itself

Reproduction

See here the reproduction repo: https://github.com/bug-reproduction/vitepress-dynamic-base

it is built off the the getting started guide

it just add the ipfs-gateway-emulator package to show case the issue when the pathname on whcih the website is unknown

Reproduction

git clone https://github.com/bug-reproduction/vitepress-dynamic-base.git

cd vitepress-dynamic-base

pnpm i

pnpm docs:build

pnpm docs:ipfs

navigate to http://127.0.0.1:8080/

and see the website is working

Now navigate to http://127.0.0.1:8080/ipfs/anyhash

and see how all the assets failed to load and page url break down

Expected behavior

I expect to be able to build a vitepress website that use only relative path , that can then be loaded from any pathname

This is a requirement for ipfs website, especially when they are loaded from localhost ipfs node that use pathname as the hash

System Info

not relevant

Additional context

No response

Validations

• Check if you're on the latest VitePress version.
• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[w8r]

Also useful if you want to build an archive website artifacts that would be indexed from outside.

[rafaqz]

Why close this without explanation?

We are looking at documentation frameworks for the julia ecosystem and this is likely a deal breaker.

[brc-dd]

There are literally tens of issues asking this. I won't keep writing an explanation when you clearly didn't search the issues and just checked the validation in issue form.

Relative base won't be supported because it will need fair amount of time refactoring all the code. It's not supported in Docusaurus or VuePress. In Astro, it's supported via a community plugin - https://www.npmjs.com/package/astro-relative-links -- Feel free to use that with their Starlight theme.

[rafaqz]

You can just link to the duplicate issue where you explain it... that saves you from reading comments like mine. The other issue linked here is also closed in the same way.

But thanks, that makes sense.

[w8r]

@rafaqz we faced the same problem (documentation versioning and relative paths) and managed to solve it with nginx rewrite rules, basically rewriting the links inside of the rendered HTML on the fly. It's nasty but it works. I hope it will help you and I hope at some point we will manage to make them reconsider this issue to support more complex projects.

[rafaqz]

Thanks but probably too nasty, we need github hosted docs for 10s to thousands of packages.

[brc-dd]

If you're hosting on GitHub why do you need this feature?

[rafaqz]

Docs aggregation. We collaborate a lot and build meta-packages. So we need relative paths.

E.g. https://github.com/JuliaComputing/MultiDocumenter.jl

[brc-dd]

Relative paths for what? Can you explain more what are you trying to do? The base in your case won't be dynamic.

That repo is just cloning docs from different repos and building navbar/sidebar and building in one go. What does it has to with "base"?

[rafaqz]

base is currently set per-repo already for the packages own documentation. I guess we will need to work out a new base path for each subpackage and do a few more replacements. Relative paths would just let us drop it in. Anyway, I think youre right it is actually doable.

[w8r]

You mean you can know at the moment of generating the docs, at which base it will end up?

[rafaqz]

For the main site they are used in, yes. But if someone wants to use the main docs of a small package in the aggregated docs of a another large package, they will need to do some string replacement on the base path or actually rebuild them with a different base path. With relative paths that isn't needed.