fix(nuxt): avoid recursive import in nitro renderer

[pi0]

🔗 Linked issue

resolves #18789

❓ 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

Nuxt renderer.ts depending on #internal/nitro exporting both useNitroApp (from nitro/runtime/app) and defineRenderHandler (from nitro/runtime/renderer which is ALSO depending on runtime/app). This makes a recusive dependency which rollup was supposed to solve, but well, it doesn't for time being :}

📝 Checklist

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

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[danielroe]

This looks good to me.

One comment: within nuxt we are now bound to the file structure of nitro despite the #internal prefix, which means we probably need to use a ~ constraint for nitropack unless we can guarantee not to change this structure until the next major release.

A second concern about this warning more generally - what about auto-imports for useNitroApp (or Nuxt composables from #app) - could that cause this to fail, again, in an end-user project, in certain situations? Options to consider:

• Auto-importing instead from the specific file rather than the index.
• Bundling some runtime directories into a single file.

wdyt?

[pi0]

I tested, it won't happen for user-land usecases. Both auto-imported useNitroApp and importing from #imports works fine (nitro has fallbacked #imports too with auto imports disabled).

#internal/app is safe but we should indeed think to switch to #imports once was sure is safe enough. It also gives typescript features.