Dynamic/relative asset paths

[ghost]

Good day!

Hope you guys are all doing well.

I have a question in regards to dynamic/relative asset paths. We are using vite-plugin-ssr in combination with an express server, meaning we are using SSR. Now, our software is built once and distributed to various environments. Some of which are changing the express router path and mount everything underneath a different path (instead of root) like /test/ or /doc/.

During the build process we also run vite build and here we run into an issue. We simply don't know where the package will end up and are therefore not able to provide a proper base path. Now, I read the official vite documentation and they actually do support a relative base setting (or no setting at all) like ./. Unfortunately this will lead to an assertion in vite-plugin-ssr.

Next I tried to use the experimental renderBuiltUrl, which works for css/svg etc but not for the js chunks etc.

After that I figured I check out the server directory and found a vite-plugin-ssr.json file which contains an object with various settings , after a build it looks like this:

{
  "version": "0.4.39",
  "usesClientRouter": false,
  "baseUrl": "/",
  "baseAssets": null,
  "includeAssetsImportedByServer": false
}

changing the baseAssets to this

{
  "version": "0.4.39",
  "usesClientRouter": false,
  "baseUrl": "/",
  "baseAssets": "/documentation",
  "includeAssetsImportedByServer": false
}

results in a stack trace (I am aware that my change is probably not something that was expected :D).

Error: [[email protected]][Bug] You stumbled upon a bug in vite-plugin-ssr's source code. Reach out at https://github.com/brillout/vite-plugin-ssr/issues/new or https://discord.com/invite/qTq92FQzKb and include this error stack (the error stack is usually enough to fix the problem). A maintainer will fix the bug (usually under 24 hours). Do not hesitate to reach out as it makes vite-plugin-ssr more robust.
    at assertPluginManifest (C:\Users\ChristophLipp\Desktop\mdd\node_modules\vite-plugin-ssr\dist\cjs\node\plugin\plugins\manifest\assertPluginManifest.js:13:24)
    at getGlobalContext (C:\Users\ChristophLipp\Desktop\mdd\node_modules\vite-plugin-ssr\dist\cjs\node\globalContext.js:33:57)
    at async initializePageContext (C:\Users\ChristophLipp\Desktop\mdd\node_modules\vite-plugin-ssr\dist\cjs\node\renderPage.js:125:27)
    at async renderPage_ (C:\Users\ChristophLipp\Desktop\mdd\node_modules\vite-plugin-ssr\dist\cjs\node\renderPage.js:30:41)
    at async renderPage (C:\Users\ChristophLipp\Desktop\mdd\node_modules\vite-plugin-ssr\dist\cjs\node\renderPage.js:155:16)
    at async C:\Users\ChristophLipp\Desktop\mdd\server\api\modules\rendering_pages_v2.js:181:29

Is there anything I forgot to try or is there something that we can configure that might help with our setup? Thanks very much and have a great day!

Cheers,
Christoph

[brillout]

I read the official vite documentation and they actually do support a relative base setting [...] like ./

How exactly would that help and how would you use it? Can you give an example of assets for which you want to have a relative base and why?

A challenge with relative paths is that they depend on the current URL. That's why VPS doesn't support them for now. (I'm not sure how/if VPS can support them.)

[ghost]

Fair enough! That is a very good question and I myself have not checked how it is being solved (.../assets maybe?).
Either way, everything you said makes sense to me and makes me think changing our deployment strategy might be the only option.

Thanks for your thoughts and opinion on this.

[brillout]

Actually, it may be possible using <base>.

I created a feature request for relative base paths: #606.

[brillout]

Btw., if your company is up for it: https://github.com/sponsors/brillout.

[ghost]

Thanks I will take this to the higher ups :) In the meantime I have sent you a small amount as a token of appreciation from my personal account @ser1us. Thanks again and have a drink on me!

[brillout]

Thanks 💚.

have a drink on me

I will, with a bavarian beer :-).