Proposal: runtime config support for NUXT_PUBLIC_UMAMI_HOST and NUXT_PUBLIC_UMAMI_ID

[AndreyYolkin]

Hello and thanks for the repo!
We have a single codebase deployed on different instances, which also have different trackers. Current implementation only checks for ENVs at build time while introduced in v3 format NUXT_PUBLIC_* makes a little confusion, as this is also a prefix for variables defined for runtimeConfig.

I suggest to make it a goal for v4 and do a refactor. I also willing to help to investigate, how to do this in the most painless way

[ijkml]

Hey @AndreyYolkin. Thanks for the suggestion, and glad you’re enjoying the module!

Sorry for the confusion. Can you please tell me a little more about your use-case and the problems you're facing?

[AndreyYolkin]

Of course!
To simplify, let's say we have a 2 environments where we launch our project. Each one has it's own settings for backend urls, keys and, particularly, analytics. We are making a build without any .env presented (except some feature flags) and later starting the output like node --env-file=".env" .output/server/index.mjs

Currently, the build process have to be aware of umami settings in order to include/exclude runtime files. But I expect at least to be able to override host/id at runtime, preserving the other params.

[YoSev]

v3 indeed removes the option to change the config during runtime, which causes an issue for us as well.
It would be nice to have a composable to change the config like umConfig().website = 'my-id'.

It should support non-SSR sites like it did in #77

[YoSev]

I added a ssr-firendly pr here, which only covers the Id so far.
More fields are possible but a bit more tricky as they are not part of the payload being send to umami, while the Id is.

#134

[froozeify]

Having the possibility to set the website could be amazing (id and website).
I'm working on an open-source project where users will be able to get the docker build image directly.
In that instance and I think many other project, giving the possibility to also update the website with env at runtime will be very useful

[YoSev]

Having the possibility to set the website could be amazing (id and website). I'm working on an open-source project where users will be able to get the docker build image directly. In that instance and I think many other project, giving the possibility to also update the website with env at runtime will be very useful

I agree. That also implies you are running a nuxt-server. A lot of nuxt users do SSG (with and without SSR) which should be supported too. In that case, you can not use env variables.

[elsell]

I would also greatly appreciate the ability for nuxt-umami to allow runtime configuration of the Umami website and ID.

We also are targeting 2 to 3 different environments that have different Umami IDs and website addresses.

As it currently stands, we have to build 3 different images - one for each environment. (With the only difference being the Umami configuration values!)

This is horribly inefficient, and a pain to manage. Especially when the rest of our app and other 3rd-party apps support runtime configuration using env vars or config files.

#120 (comment) is relevant to this discussion

[YoSev]

As of my pr #134, only the id can be changed as it is part of the actual payload being send to the umami server. I can add support for more settings in the same way which is a bit more complicated as those fields are more of a configuration then part of the payload. I would do that in a separate pr in case the first one gets merged.