BaseURL + Uncommon Configuration With Reverse Proxy

[wanton hare]

We have a Nuxt3 app which we have created which is intended to be deployed to various locations as a Docker container.

The container gets mounted sometimes at the root of a url (https://www.somedomain.com/) and sometimes it gets mounted as a subdirectory, with an NGINX reverse-proxy sitting in front of it. (https://internal-domain.somedomain.com/nuxtApp/)

Ideally, we would configure this at runtime by passing a NUXT_APP_BASE_URL paramater of /nuxtApp/ when hosting on the sub path, but from the Nitro server's perspective, this outputs the rendered HTML looking for the following path: https://internal=domain.somedomain.com/nuxtApp/nuxtApp/_nuxt/entry.js

We have tried manually configuring the NUXT_APP_CDN_URL as well as the NITRO_APP_BASE_URL. The closest we have been able to get it functioning was to configure the CDN to point at /nuxtApp/ with a baseURL configured of /, but then the front end vue router seems to get lost and tries to forward us to /nuxtApp/nuxtApp/

It appears the NITRO_APP_BASE_URL seems to override/replace the NUXT_APP_CDN_URL, so we cannot independently control the NITRO server from the NUXT app (and the expected pathing of the vue router itself)

Really at a loss of how to set this up.

Any ideas would be GREATLY appreciated in trying to solve this.

[daring plover]

I'm having this exact issue. Is there anyone who could shed a bit of light on how to do this? Would be greatly appreciated 🙂

[winged veldt]

@wanton hare did you ever find a solution for this?

[wanton hare]

So we ended up writing a custom server plugin (last one which runs) which modifies the outbound payload of a request:

export default defineNitroPlugin((nitroApp) => {
nitroApp.hooks.hook('render:response', (response) => {
const pathPrefix = getPathPrefix();
const config = useRuntimeConfig();
const newPath = ${pathPrefix}${config.app.buildAssetsDir}.replace('//', '/');
const pathRegex = new RegExp(config.app.buildAssetsDir, 'g');
response.body = response.body.replace(pathRegex, newPath, 'g');
});
});

And we modified the Vue router with a app/router.options.ts which sets up the client router with our concept of a path prefix:

export default <RouterConfig>{
history: (base) => {
const pathPrefix = getPathPrefix();
return createWebHistory(pathPrefix || base);
},
};

Then a nuxt plugin (very first nuxt plugin which runs) which sets things up on the client side:

export default defineNuxtPlugin({
order: -40,
setup: (nuxtApp) => {
const pathPrefix = getPathPrefix();
if (!pathPrefix) return;

    const currentPath = window.location.pathname;
    const modifiedPath = currentPath.replace(pathPrefix, '');

    nuxtApp.payload.path = modifiedPath || '/'; // We are running in a subdirectory, so we need to set the path to root
},

});

All make use of a util for getting the pathPrefix from our runtime config:

export const getPathPrefix = () => {
const {
public: { pathPrefix },
} = useRuntimeConfig();
return pathPrefix.endsWith('/') ? pathPrefix.substring(0, pathPrefix.length - 1) : pathPrefix;
};

Not ideal, but it works. @winged veldt

[winged veldt]

@wanton hare Not sure if I missed something but the router options are throwing the following error.

500
window is not defined

at Module.createWebHistory (./node_modules/vue-router/dist/vue-router.mjs:714:31)
at Object.history (./app/router.options.ts:8:34)
at setup (./node_modules/nuxt/dist/pages/runtime/plugins/router.js:52:61)
at ./virtual:nuxt:/development/binarymelon.com-nuxt/binarymelon.com/.nuxt/plugins/server.mjs:38:89
at Module.executeAsync (./node_modules/unctx/dist/index.mjs:111:19)
at setup (./virtual:nuxt:/development/binarymelon.com-nuxt/binarymelon.com/.nuxt/plugins/server.mjs:38:65)
at ./node_modules/nuxt/dist/app/nuxt.js:116:60
at fn (./node_modules/nuxt/dist/app/nuxt.js:192:44)
at Object.callAsync (./node_modules/unctx/dist/index.mjs:68:55)```

[sullen dirge]

(window only works on the client-side and not when using SSR)

[winged veldt]

Isn't router.options.ts the client side router?

@sullen dirge

[sullen dirge]

needed on both sides

otherwise how would the server determine the routes? 😋

[winged veldt]

Anyway, disabling ssr got around that issue, but @wanton hare I'm guessing this is only intended to work for prod builds? All my vendor modules still don't have the prefix. I guess a little bit of background. I'm trying to run this in dev mode on a self hosted code-server which is behind a reverse proxy. code-server than proxies the server to subdomain.mydomain.com/proxy/3000.

[wanton hare]

Yeah, we have ssr disabled, sorry, forgot to mention that.