Run & review this pull request in StackBlitz Codeflow.

I'm wondering about the best location for this (and possibly other options) for the head - maybe instead in head or in app.head. I'm worried this will clutter features. What do you think @harlan-zw?

If a features Nuxt line break config was going to be added it should handle the line breaks for the entire document, not just the head so I'd say this isn't the right place for it.

Having a way to pass options to the Unhead functions would be the most future proof and it would make sense for that config to exist within the head modules config that is under the meta key. (although we should probably rename this to head or unhead for v4)

export default defineNuxtConfig({
  meta: {
    renderSSRHead: { // typeof RenderSSRHeadOptions @unhead/schema
      ssrOmitLineBreaks: true,
    }
  }
})

I don't really see a reason why this can't be enabled by default in a production environment for v4 either 🤔 Could also be the default of Unhead v2 if I have time to get to this before v4

I am currently following the conclusions of unjs/unhead#297 and have set omitLineBreaks to be disabled by default. However, I think it would be great if omitLineBreaks could be enabled by default in the production environment!

Also, concerning the type of meta.renderSSRHead, if it is expected to align with the RenderSSRHeadOptions from @unhead/schema, perhaps we could structure the configuration as follows to ensure consistency. Additionally, would it be more appropriate to use renderSSRHeadOptions instead of renderSSRHead?

export default defineNuxtConfig({
  meta: {
    renderSSRHeadOptions: { // typeof RenderSSRHeadOptions @unhead/schema
      omitLineBreaks: true,
    }
  }
})

Moreover, as we anticipate the name will change to head or unhead in v4, could we consider adopting this naming convention in v3 to maintain continuity?

I don't think either meta or head currently exists in the Nuxt config options, so I think we're good to add a new key without any issues (though head would conflict with Nuxt 2 types - so it might create issues for module that support both Nuxt 2/Bridge and Nuxt 3 🤔)...

It appears that our decision to use meta as the key in v3 might be a more suitable choice.

Additionally, should we set the schema part in schema/src/config/app.ts?

I wonder about using unhead rather than head or meta. It would match vite, postcss, etc...

I didn’t put much thought into the name initially, but now that I’ve thought it over, unhead actually sounds like a better choice. It clearly points out where our dependencies come from and helps us avoid any mix-ups.

Should we change it to unhead then?

I think likely, though I'd love feedback from @pi0 and @harlan-zw particularly. 🙏

The bit in schema is an (untyped) backwards-compatible bit. We'd likely need to keep the backwards-compatibility, but people really shouldn't be using it at this point.

We've decided to add unhead key to schema that allows configuring the unhead nuxt module directly, which will unblock configuration of advanced use cases (linking #27031 for headNext support). Would you be happy to update this PR? 🙏

Looks good minus the comment. I'm guessing this will land in v3.12 so probably we want to minimise any new behaviour until v4.