Links to public/ files are wrong when a base URL is used

[catrope]

1. Put a file called foo.json in the public/ directory
2. In an .md file somewhere, create a link like [look at this JSON file](/foo.json)
3. Build the site. The link works.
4. Change the VitePress config to add base: '/base/
5. Build the site again. The link doesn't work: it erroneously points to /foo.json, but it should point to /base/foo.json

[MarkusKeck]

I tested it multiple times and can confirm that absolute paths of links [look at this JSON file](/foo.json) ignore the base URL.
Relative link paths and absolute image paths work like expected.

    base: '/TEST/', // config.ts

![IMAGE](/bitelligence-training-og.png)

[JSON ABSOLUTE](/foo.json)
[JSON RELATIVE](./foo.json)

From the docs

All your static asset paths are automatically processed to adjust for different base config values.
https://vitepress.vuejs.org/guide/asset-handling#base-url

Internal links are converted to router link for SPA navigation.
https://vitepress.vuejs.org/guide/markdown#links

I have not looked into the building process of the routes, but I assume that an easy fix would be to add the withBase to the internal links
https://vitepress.vuejs.org/guide/api#withbase

[brc-dd]

The problem here is do we know if you're writing /foo.json, it is going to be internal 👀. What if someone wants to have a file at foo.com/bar.json and have vp deployed at foo.com/baz/ and we prefix that link so that it becomes foo.com/baz/bar.json, in this case that link will break, won't it 👀

[MarkusKeck]

@brc-dd True, even If I think it is more desireable to construct a link which includes a basepath. If you really want to point to an external file you should use an url https://.... like you would with every other url (wikpedia, github, ...) In my opinion this behaviour would be more consistent, also the current documentation states that base is supported with static assets / references. https://vitepress.vuejs.org/guide/asset-handling#base-url

I could take a deeper look at this if you find this worth changing @brc-dd

[catrope]

The problem here is do we know if you're writing /foo.json, it is going to be internal eyes. What if someone wants to have a file at foo.com/bar.json and have vp deployed at foo.com/baz/ and we prefix that link so that it becomes foo.com/baz/bar.json, in this case that link will break, won't it eyes

Sure, and there should be a way to link to something at the domain root if I really want to (perhaps by using a URL like @MarkusKeck) suggests. But the reason I was expecting it to work the way I described in my bug report is because VitePress's own documentation says that it should:

Assets placed in public will be copied to the root of the dist directory as-is.

Note that you should reference files placed in public using root absolute path - for example, public/icon.png should always be referenced in source code as /icon.png.

There's no caveat here along the lines of "except if you're using a base path, then this doesn't work". At the very least the documentation should be updated so that it correctly describes the actual behavior. But I'd argue for fixing this bug, or providing some other way of reliably linking to public files. The public feature is close to useless if there isn't a reliable way to link to those files without having to hard-code the base path all over the place, and without an easy way to refer to the base path for setups (like mine) where the base path is dynamic (we build the same site for different targets, with each target using a different base path).

[MarkusKeck]

Here is a quick update on the error that is occurring. I have already read deeper and found a working fix. However, I have noticed that there are many individual exception rules for different links, which then contain additional exceptions depending on the environment. For this reason, I think it makes sense to invest some more time in a solution that is satisfactory and consistent for all types of links.

@catrope If it is interesting for you or you want to have a quick solution for the currently occurring behavior, you are welcome to take a look at the current handling of links in Vitepress. vitepress/src/node/markdown/plugins/link.ts