nitrojs
allow syncing runtime config with full stack frameworks without depending on imports
Context: https://github.com/nuxt/nuxt/issues/14919
~~globalThis.__nitro__.useRuntimeConfig() could be useful for frameworks to use nitro runtime API without depending on bundler imports -- mainly for prerenderer preoptimizations --~~
(update: looking for a more secure way to allow access without imports but also avoid exposing nitro internals to globalThis)
I'd like to help, but I am very confused about where to start. I'll send you a string of dumb questions on discord, and then summarize the answers here when I feel like I have a better understanding of what needs to happen.
We need to consider the security implications of exposing user provided variables in the global scope like this.
We need to consider the security implications of exposing user provided variables in the global scope like this.
I don't think there is any security concern API lives in the same context (server runtime).
No response on Discord, so I'll copy it here:
What I mainly don't understand, is:
- why we want to expose a function via
globalThisrather than importing. Since nitro is a dependency of nuxt, it should always be available to import, right? - why this would help to solve the prerender/build entanglement (I'm willing to ignore this question and just take your word for it, if it's hard to explain)
@pi0 I would love to move forward with this, but I need some guidance, please. See my questions above.
Hi dear @rudolfbyker sorry was little busy in past weeks and forgot to followup on this.
why we want to expose a function via globalThis rather than importing. Since nitro is a dependency of nuxt, it should always be available to import, right?
Nitro it is a dependency of nuxt that's correct. Also we currently directly import useRuntimeConfig in nuxt app. But that's the problem! Because of this import, we have a direct (bundling) dependency between nuxt and nitro and that requires the prerenderer to need bundling nuxt app as well in order to have direct access.
No problem @pi0 :)
I think I'm starting to understand. So this is a kind of workaround to get around the bundler's default behavior?
Adding something to globalThis is a side effect, obviously. But I'm not 100% sure when this side effect should happen. Is there an example of something else in this repo that already follows the pattern of adding things to globalThis, so that I can see when it happens?
Because as far as I understand, if you just have globalThis.foo = bar somewhere in a file, it will only run once that file is imported, anyway. So when does this import happen? :thinking:
It can leave anywhere in entry (config.ts should also do this) because we lazy load nuxt routes they surely happen after that code being executed.
I struggle to understand your last message. Sorry!
It can leave anywhere in entry
- Do you mean "live"? Sorry, not trying to nit-pick. Just confused.
- What do you mean by "entry"?
- One or all of these files? https://github.com/unjs/nitro/tree/main/src/runtime/entries
- The index.ts (or dist/index.mjs) file?
config.tsshould also do this
Do you mean this file? https://github.com/unjs/nitro/blob/main/src/config.ts
I see defineNitroConfig made available as globalThis.defineNitroConfig at https://github.com/unjs/nitro/blob/main/src/options.ts#L144 . Should that also move to globalThis.__nitro__.defineNitroConfig at some point? :thinking: If so, maybe there should be a centralized place where __nitro__ is populated, so that we can write types for __nitro__ more easily.
For now I guess we can simply set globalThis.__nitro__.useRuntimeConfig right after the function definition? Or did you mean to say that the globals need to be set in each one of these files? https://github.com/unjs/nitro/tree/main/src/runtime/entries