globals scripts defined at build-time prevent multi-instance deployments with different third-party IDs

[agracia-foticos]

🆒 Your use case

Problem: Third-party scripts registered via scripts.globals in nuxt.config.ts (e.g. Trusted Shops, Awin, Scrads) have their IDs and src URLs baked into the bundle at build time. It is not possible to change them per server instance without rebuilding.

Use case: Single build, multiple deployments — each instance has different Trusted Shops / Awin / Scrads account IDs set via environment variables.

🆕 The solution you'd like

Expected behavior: Either (a) allow globals entries to reference runtimeConfig values, or (b) provide a composable/plugin API (e.g. useScript() with a src derived from useRuntimeConfig()) that registers global scripts lazily at server request time rather than at build time.

🔍 Alternatives you've considered

Note: The trigger: 'manual' option is already used, so lazy initialization is already part of our setup — the blocker is purely the static src URL with the embedded ID.

ℹ️ Additional info

No response

[harlan-zw]

Hi @agracia-foticos, thanks for the detailed write-up on this one.

Shipped in #780 (will go out in the next release).

How it works: each entry under scripts.globals now exposes its input via runtimeConfig.public.scriptsGlobals at build, and the generated plugin merges that runtime config over the build-time default before calling useScript. That means any field (src, integrity, custom data-* attrs, etc.) is overridable per deployment via Nuxt's standard env vars, e.g.:

NUXT_PUBLIC_SCRIPTS_GLOBALS_TRUSTED_SHOPS_SRC=https://widgets.trustedshops.com/X1234.js

If you need anything more complex than that, it's definitely recommended to just use useScript() itself (or the registry scripts) in a Nuxt plugin.

If you have any ideas for further improvements, let me know.

[agracia-foticos]

Follow-up from the single-build multi-instance use case:

Thanks for shipping the scriptsGlobals runtimeConfig override in v1.1.0 — it's a step in the right direction. However, after implementing it we hit a fundamental limitation with the globals approach for multi-tenant/multi-instance deployments:

The problem: globals entries are compiled into the virtual plugin at build time. Even if a particular instance doesn't use a given integration, the script entry still exists in the bundle and in the scriptsGlobals payload for every instance. The runtimeConfig override only allows mutating values of existing keys — you can't conditionally remove an entry at runtime.

Our workaround: We moved away from globals entirely and load scripts conditionally in a client-side Nuxt plugin by reading tenant config from runtimeConfig.public and calling useScript() directly only for active integrations:

This works, but it loses the benefits of globals (SSR-aware registration, type-safe useScriptXxx composables, automatic bundle handling).

Feature request: Would it be possible to support a globals factory function that receives runtimeConfig and returns the entries dynamically at server startup? Something like:

This would enable true per-instance script configuration without rebuilding, while keeping all the globals DX benefits.

[harlan-zw]

See #808