fix(cloudflare-pages): pass CfRequestContext to nitro localCall

[dario-piotrowicz]

🔗 Linked issue

#773

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

in the cloudflare-pages adapter I've added the CfRequestContext that the onRequest function receives from Cloudflare to the nitroApp localCall so that users can access such context in their nitro application

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[dario-piotrowicz]

Note: this needs to be called context and not cf (as suggested in the comment) because unenv takes this specific context field and puts it in the req.__unenv__: https://github.com/unjs/unenv/blob/4ed234cf8fd88264852739d14b40bebf7ce31afe/src/runtime/fetch/call.ts#L51
(which is where then users can have access to it)

[pi0]

Sure but it can be nested like here: https://github.com/unjs/nitro/blob/7bcfc362a77764aed566b9f266ae702ccd0dceed/src/runtime/entries/cloudflare.ts#L36

[dario-piotrowicz]

ah yeah good point

in the current way it makes getting the value from nuxt quite clean just via event.context.env.
if I nested it with something like cfContext it would be: event.context.cfContext.env
which is not as clean, but not terrible either (note, I can add the cf later that is a different unrelated object)

would you prefer that I nested the value?
(PS: it could actually help if/when we add cf as well 🤔 )

[pi0]

It is intentionally verbose because we are accessing a platform-api. cf is already added for normal worker target. we need to add it it for pages too (i suppose interfaces are same)

[dario-piotrowicz]

ah by the way, regarding the cf we I don't think we need to manually pass it since it will accessible from the ctx.request anyways

eg.

so it looks like context: ctx, should actually be enough, what do you think?

or alternatively we can and choose what fields from the CfRequestContext pass along, in that case we could construct the context ourselves, but I am not sure if that's needed/beneficial

[pi0]

event.context.cf can have all the keys and context passed by cloudflare by using context: { cf: ctx } that simple :)

[dario-piotrowicz]

mh.... ok, but if we do that then if someone uses the worker adaptor then the event.context.cf will contain only the cf object whilst with the pages adaptor event.context.cf will contain the CfRequestContext, those are two very different objects, so this might lead to confusion?

if you are ok with this misalignment of the two I am as well, I'd also want to update the worker adaptor anyways in a followup PR to make it use the ESM syntax (which is needed to pass things cleanly there as well, and also in order to have access to some services like DOs), so I could re-align them there (but I wanted to get this pages change out of the way asap so that people can start using Nuxt on Cloudflare pages, the worker adaptor refactoring is not that pressing)

[dario-piotrowicz]

@pi0 I've updated the code as you suggested, please have a look 🙏

[dario-piotrowicz]

@pi0 sorry to bother you, could you help me understand why the deployment's failing?

[pi0]

Failed docs deployment is okay :)

[dario-piotrowicz]

No longer needed after #1004