Disable payload extraction for nuxi build

[pi0]

Followup nuxt/framework#8890 by @danielroe

There are currently some uncertain decisions about the final API and behavior with payload extraction behavior like how we apply payload updates on CSR route change (should the key of static payload be prefixed with routes as well or remain global same as asyncData keys). (Tracker issue: #14507)

Making the decision to enable this feature or not is a tricky one because on one hand, we are really close to v3.0.0 release deadline and we don't want to mark a functionality as stable and change it in a semver-minor release and on the other hand, payload extraction is an essential feature for the release with full static generation support.

I suggest two behaviors:

• For nuxt build when we have a server and the possibility of having hybrid prerendering, disable an option by default. Payload extraction will be always opt-in in Nuxt 3 for server mode.
  • Docs: Deploy>Node.js Server https://v3.nuxtjs.org/getting-started/deployment#nodejs-server
• For nuxt generate when we are expected to output a "full static" output, enable the future
  • Update the docs and warn about the stability of nuxt generate
  • Explain how payload extraction works and what are consequences of disabling it (needing a server)
  • Docs: Deploy> Static Hosting https://v3.nuxtjs.org/getting-started/deployment#static-hosting

An alternative is to always disable feature until we are really sure it is stable but there are few downsides:

• Enabling it by default for nuxt generate, even if super stable, is still a breaking change considering we essentially change caching strategy
• Enabling it with a new flag (nuxt2 was target: 'static') is less intuitive for starter users and even more confusing to explain
• Differing to enable, means also less usage of the feature and harder to ever stabilize it

[kilobyte2007]

One related thing that is quite confusing to me is also what is the exact result of the build and prerender/generate commands.
For example, I have a project where I want to have the option to do both:

1. Server Side Rendering without prerender - which runs with nuxi start for previewing changes live.
2. Full Static website which is prerendered and the .output/public directory is deployed to a static hosting.

As for now if I run nuxi build and then npm start the website is not dynamic as it uses pre-rendered routes which is not what I need for case 1.

I've seen there is a nuxi build --prerender=false command option but it seems to be ignored and the routes are still pre-rendered.

I think it would be good to be able to have different commands or flags for different scenarios so we can run the same project in several modes without the need to change the config.

As for your suggestions, I think the two behaviors you suggested make sense if we don't consider the caching strategy issue.

[pi0]

Dear @kilobyte2007 are you using nitro.prerender.routes: [] option by any chance? By default output of nuxi build should be server bundle without any pre-rendered routes as you expected in (1) scenario and when using nuxi generate, second scenario that no production server is generated and all routes all generated as full static.

[kilobyte2007]

Hey @pi0, yes we are using the nitro.prerender.routes option and filling it with routes that we need to prerender.
The thing is that we wanted to use the routes option to prerender the pages in order to deploy as a static website but to still have the option to build in server mode in order to deploy on our staging server, where pages should not be pre-rendered at all.

[Atinux]

Happy to disable it by default for nuxi build and enable it for nuxi generate

[Atinux]

Something to note is that the experimental feature shall be false by default IMO

[pi0]

Happy to disable it by default for nuxi build and enable it for nuxi generate

nuxt/framework#9018

Something to note is that the experimental feature shall be false by default IMO

Currently we have some flags in experimental that is enabled but also kept supporting in this namespace to opt-out as an escape hatch if anything goes bad with them. externalVue, treeshakeClientOnly, viteNode, viteServerDynamicImports, inlineSSRStyles included as of today.