Rupert Dunk

Thanks for the report. `@nuxtjs/sanity` uses it's own portable text serializer OOTB. Are you using `` in your application?

Closing as this is expected behaviour.

Hello, this starter is for [Vercel Visual Editing](https://vercel.com/blog/visual-editing). The starter you've linked to is for [Sanity Visual Editing with Presentation](https://www.sanity.io/docs/introduction-to-visual-editing). As far as I'm aware we plan to continue to...

Thank you so much for the thorough report. It's immensely helpful for us when people take the time to raise issues in this way. I do remember initially trying to...

So I'm not seeing quite the same results as you using our Nuxt starter. I do see a slight increase in the entry size, but the same number of files....

Essentially, I can just see the entry file size is increased because of the `createQueryStore` and `defineEncodeDataAttribute` imports from `@sanity/core-loader` in [this file](https://github.com/nuxt-modules/sanity/blob/main/src/runtime/composables/visual-editing.ts).

Right, but the `enableLiveMode` and `renderVisualEditing` modules are both lazy loaded internally by `@sanity/core-loader` only when the wrapper functions are called, so although these files will be output at build...

That is very strange, I don't think `pages: true` should make a difference. I'm testing this using our [Nuxt template](https://github.com/sanity-io/sanity-template-nuxt-clean). Can you check that you aren't seeing any `` element...

Ahh right. I see the issue you're describing now! I believe this is Nuxt's default behaviour, to `prefetch` these scripts, i.e. non-blocking low priority vs. `modulepreload`. My understanding was that...

Having done some investigation, it looks like we would need to use the Nuxt's `ssrContext.head` to hook into `entries:resolve` in order to remove these entries in a server plugin. However,...