Allow setting `baseURL` at runtime

[jvllmr]

Describe the feature

I am currently deploying a new TanStack Start app with node server in containers.
We like to use custom basepaths for production and staging systems and I'm used to setting a new basepath at runtime from other projects, but nitro sets the basepath in the index.mjs file at build time.

It would be great if even after build the basepath can be modified via an env var.

Additional information

• Would you be willing to help implement this feature?

[ennioVisco]

What would be the benefit of having the basePath editable at runtime? I really cannot imagine any use case

[jvllmr]

The key benefit is that I don't need multiple build pipelines/container images. That saves resources and time.

Next is not my case, but if a customer has special requirements for their hosting, I don't have to create an extra container image for them.

Last but not least: It's simply a feature I except from good web server implementations/standards such as i.e. WSGI/ASGI implementations in the python ecosystem or enterprise-grade software in general.

[ennioVisco]

Ok now I get better what you need:

• you don't need to be able to change it at runtime
• you need to have a configuration that allows to set it on startup without having to rebuild it

This makes more sense, but then why not setting NITRO_APP_BASE_URL in the running environment? -> https://v2.nitro.build/config#baseurl

What does it not cover of this use case?

P.s. I'm quite familiar about the typical enterprise setups. If something is common, that doesn't mean it's good: it's a world dominated by a lot of legacy practices that just resist simply as a habit

[jvllmr]

Oh yeah, sorry for the misunderstanding 😅

I've tried using NITRO_APP_BASE_URL at startup, but it did not really work for me.
When looking into the index.mjs from a build with baseURL set, I saw that the used pathprefix was hardcoded at multiple places in the generated file. So I assume NITRO_APP_BASE_URL is meant to be used when building.

I know that using different basepaths for different deployments is not really best practice, but as you mentioned I also suffer from questionable policies/habits that require me to use basepaths instead of sub-domains...

The obvious solution here still is to create different builds for different deployments, but that would not be elegant to me.

[pi0]

Supporting dynamic baseUrl at runtime has a (per request) cost since we have to either clone whole request or make a proxy wrapper (feature added in h3js/h3#1342) + bundle size for all users unless gated behind a flag.

I think in nitro, we can somehow have an opt-in feature to allow supporting runtime base url, as i fully undrestand there might be valid usecases for it.

[ennioVisco]

Why would it have bundle impact? I'm not fully aware of what happened in V3, but couldn't something like a read-only env variable be used for that? The use case is simply for it to be configurable, not to be reactive

[pi0]

The use case is simply for it to be configurable,

Yes! We need some build config like features.runtimeBaseURL: true that injects runtime code to the bundle that dynamically reads NITRO_APP_BASE_URL env and wraps incoming request in app entry (virtual template) with h3.requestWithBaseURL.

Why would it have bundle impact?

Nitro v3's output is very minimal (try building a hello-world with standard preset), we only incude logic that is explicitly used by user. request wrapping logic and reading env costs bundle size.