feat(nuxt): add support for routeRules defined within pages

[danielroe]

🔗 Linked issue

❓ 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)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This adds the ability to define routeRules inline, within the pages directory.

Example usage:

<script setup lang="ts">
defineRouteRules({
  ssr: false
  prerender: true,
  headers: {
    'X-Test': 'defined within a page'
  },
})
</script>

TODO:

• feedback on API
• implement HMR support in dev mode (currently nitro's runtimeConfig is frozen so we can't update it there). I might consider overriding event.context._nitro.routeRules but this would also miss out getRouteRulesForPath being called directly 🤔
• documentation updated

📝 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

[Atinux]

I love it!

[Hebilicious]

I was just thinking about this, would it be possible that we generate some kind of artifact file that reflects the route rules state ?
Something like a routeRules.json, maybe in the app or .nuxt directory. I think it could be helpful to know what's going on as the configuration can come from many different places with this change (ie defineRouteRules can be used through modules/layers). It will be useful to debug what happens, and know how the rules are generated.

Perhaps also add a tab to the devtools ?

[danielroe]

/ecosystem-ci run sanity-module

[nuxt-ecosystem-ci]

📝 Ran ecosystem CI: Open

suite	result
sanity-module	✅ success

[danielroe]

@pi0 Would love your thoughts here. In dev mode, the first request to any page with inline route rules (that is, the one that triggers a nitro reload) causes a 404 response.

This is also the same issue that #22494 works around - when nitro reloads its dev server it seems to return a 404 to any simultaneous request, rather than 'waiting' for the reload and then returning the response.

[harlan-zw]

One concern would be if other modules are also updating the route rules at runtime, it seems like they would get overridden?

I think the scope for this happening, especially just in development, is pretty low.

Maybe worth merging in nitro.options.routeRules though?

[danielroe]

I think we can use nitro.options._config.routeRules to access the un-normalised rules.

cc: @pi0 - thoughts on how to avoid clobbering pre-existing route rules?

[pi0]

I guess merging with nuxt.options.routeRules would be safer as it contains the latest user (nuxt module) modified rules. In context of Nuxt with top level routeRules, it should be main source of trust.

(we sync runtimeConfig from nuxt to nitro. might need to do a similar fix for route rules as well to make this possible)

[danielroe]

nitro:config hook is last place for modules to modify nitro config, so that might be safer. (Hence current and previous implementations.)

Otherwise when we update the rules we overwrite intervening changes.

Or maybe use proxy for runtimeConfig/routeRules in resolved options that automatically reloads both within nitro?

[pi0]

Modules might need to also apply route rules afterward as well (similar to runtimeConfig). We can either sync references so that nitro and nuxt modules update same object or proxy is also good idea for auto reload 👍🏼 (a possible downside is that sometimes we need to batch changes, advising to prefer update config hook is safer)

[danielroe]

How about instead letting nitro keep track of current state and only merge in/reload the updated rules? That way we wouldn't overwrite anything or need to implement proxy/etc within Nuxt...

[harlan-zw]

Nice 👍

[pi0]

This is a really nice initiative! I would recommend to enable it behind an experimental flag until next minor release if want to move forward faster. Coupling with nuxi to support HMR on nuxt.config and also route rule / event handler meta inlined support from Nitro, might affect this implementation and possibly introduce regressions affecting user experience.

[Atinux]

It is looking great 😍

Agree to test with an experimental flag until Nuxt 3.8