Closed wighawag closed 3 months ago
Also useful if you want to build an archive website artifacts that would be indexed from outside.
Why close this without explanation?
We are looking at documentation frameworks for the julia ecosystem and this is likely a deal breaker.
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.
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.
@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.
Thanks but probably too nasty, we need github hosted docs for 10s to thousands of packages.
If you're hosting on GitHub why do you need this feature?
Docs aggregation. We collaborate a lot and build meta-packages. So we need relative paths.
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"?
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.
You mean you can know at the moment of generating the docs, at which base
it will end up?
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.
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 unknown3 uses cases where this happen:
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
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
Additional context
No response
Validations