nuxt-security: Error deploying to Cloudflare Workers after upgrade beyond rc.2

Issue is with nuxt-security module in /src/runtime/nitro/plugins/05-cspSsgPresets.ts#L2 you should never ever import @nuxt/kit or nuxt builder dependencies in runtime. It will cause part of Nuxt to build dependencies (including giget that is not even meant for runtime) to be bundled and in workers, causing this issue.

/cc @danielroe it happened again… I will try to check import protection. (~> https://github.com/nuxt/nuxt/pull/25162)

Hey @pi0 I’ve created a minimal reproduction here.

I’ve setup an empty nuxt 3.9.1 project, add nuxt security and some basic configs.

There is a GH Action that runs the build for NITRO_PRESET=cloudflare_pages

The build fails on GH Actions.

Example Project, PR that fails to build

Failing Build GH Action here

Hey guys,

I have just published a 1.0.1 version where we removed the part of the code that was causing the issues. We will refactor it for the next major version that we want to release next week probably (1.1.0)

Sorry it tooked so long but we wanted to refactor the code without disabling functionality but we didnt make it so we will do it in the next release.

Could you please verify if the issue is gone?

Another issue related to this code was fixed in 1.0.1

I think it is probably safest that you disable this flag in meantime. CSP should ideally come to the nitro/nuxt core for proper support in all conditions.

I also made an upstream idea in nitro https://github.com/unjs/nitro/issues/2119 that it can allow same solution you currently do, little more generic so similar usecases can leverage.

Otherwise @danielroe is correct, useNitro is build time and useNitroApp is runtime.

@Baroshem Thank you for this, I can confirm my build now works with 1.0.1

@vejja

I have been thinking more about maybe refactoring the implementation to not remove a useful functionality.

@pi0 do you know if there is a way to refactor this preset plugin for nitro so that it wont break the deployment in cloudflare but will still make it work?

Hi @Baroshem I think a full refactoring is required. However I do think that #298 lay the proper foundations for that. I need to better understand what @huang-julien is doing with the context, I’ll have a deeper look

useNitro() is available as an auto import.

Hi @pi0 I can’t import useNitro(), is there something specific I should do ?

FYI we have

• imports.autoImport=false in .nuxtrc
• { "extends": "../../../.nuxt/tsconfig.server.json" } in src/runtime/nitro/tsconfig.json

Thanks to your comment @pi0 I was able to make the right assumptions when looking through my package.json. Looks like the culprit was a plugin to generate sitemaps (nuxt-simple-sitemap, https://www.npmjs.com/package/nuxt-simple-sitemap, v3.1.7) which worked fine with nuxt 3.8.4 but caused the build error with cloudflare in nuxt 3.9.1. The simple fix was to bump this package up to its latest version 5.0.1 (they’ve also renamed it to @nuxtjs/sitemap).

Thanks again everyone for your help on this, even though your work wasn’t causing the bug at all. It also made me aware that your package exists. 😃

I wonder what other package causes it for you @1mak

On my example project, if I remove nuxt-security it works fine.

https://github.com/unr/nuxt-security-failed-deploy-example/pull/2

@vejja @pi0

Thanks for your input. Let’s wait some time for guys who reported the issue for reproduction maybe so that we can avoid publishing a new version that wont fix an issue but could break something else 😃

Hey @1mak

Thanks for reporting that! I dont think it is related to NuxtSecurity either (at least the core functionality) but more about its dependencies (giget) or dependency missmatch. I will await for @pi0 here to help us as giget is a package from unjs

I am seeing the exact same issue with nuxt 3.9.1 and nuxt 3.9.1 using cloudflare pages. I also thought it’s a dependency mismatch between node-fetch-native 1.4.1 and 1.6.1 but I could be wrong.

Edit: I don’t think this issue is related to nuxt-security as I don’t have this plugin installed.

Thanks @unr and @vejja for additional details.

I think that we would need a help from @pi0 here 😃

Yes, definitely

In the meantime, would @unr be ok to try upgrading nuxt to 3.9.1 ? The fact that pnpm-lock.yaml was upgraded there might help giget to find node-fetch-native

@Baroshem I can see that the log from @unr is trying to use node-fetch-native from nitropack@v2.8.1 which I understand is v1.6.1 Our module pins node-fetch-native to v1.4.1 in yarn.lock Maybe upgrading our dependencies would help ?

Update: More clues

• Our yarn.lock pins nitropack to v2.8.0 which in turn pins node-fetch-native to v1.4.1
• nitropack@v2.8.1 updated node-fetch-native to v1.6.1
• node-fetch-native v1.5.0 introduced proxy support, which is what the log is saying it cannot find
• Up until nuxt@3.8.2, nitropack was pinned to v2.8.0; after that it was upgraded to v2.8.1
• The pnpm-lock.yaml file of nuxt@3.9.0 incorrectly pins node-fetch-native to v1.4.1. This was corrected in nuxt@3.9.1

I cannot be 100% sure but it looks like a giget problem. I understand giget has its own dependency resolution algorithm, maybe the fact that the issue only appears in workers environments is a hint that giget cannot resolve the correct version of node-fetch-native there.