feat: expose module identifier

[OskarLebuda]

An opt-in option for SSR setups. It is a no-op unless you pass it, so nothing changes for existing users.

exposeModuleIdentifier

Attaches a stable identifier to each component, so an SSR runtime can map the components it rendered back to their chunks and preload the right CSS/JS.

exposeModuleIdentifier?:
  | boolean   // -> internal hash() of the module request
  | ((request: string, ctx: { resourcePath: string; rootContext: string }) => string)

v15 did this itself via componentNormalizer.js#L56-L57. It was dropped in v16 and never replaced (vue-loader#1887, open since 2021, confirmed as "planned but not yet implemented"). Two PRs tried to restore it and are still unmerged: #2079 and #2083.

Both register into ssrContext._registeredComponents with a fixed hash. This PR only exposes the value instead, because consumers disagree on both parts:

• The sink: nuxt/nuxt#27819 already replaced _registeredComponents with ssrContext.modules.
• The value: Nuxt keys by relative path, vue-server-renderer by hash-sum of the request, #2083 by sha256, and it flags the clash itself.
• Everyone already patches around it: Nuxt ships a second loader just to append this property. We maintain a fork for the same reason.

The name __moduleIdentifier matches v15 and Nuxt's mixin, so existing consumer code works unchanged. The value goes through propsToAttach like __file, and the |<hash> suffix from inline match resources is stripped so it lines up with Module.identifier().

Registering into ssrContext on top of this is a few lines consumer-side. Happy to move it into the loader instead if you prefer.

[chenjiahan]

Thanks for working on this! The module identifier option looks good to me.

I noticed two issues with the server HMR changes:

• SSR builds import ssrRender, but the generated template update callback still calls api.rerender(id, render). I reproduced a ReferenceError: render is not defined when applying a template update.
• The imported-type watch hook only invalidates clientCache, while server builds use serverCache. Changes to imported prop types can therefore leave the server using stale compiled results.

Would you be open to moving the server HMR changes into a separate PR? That would let us review the update behavior and add tests for actual SSR template and type updates independently.

[OskarLebuda]

Thanks for working on this! The module identifier option looks good to me.

I noticed two issues with the server HMR changes:

• SSR builds import ssrRender, but the generated template update callback still calls api.rerender(id, render). I reproduced a ReferenceError: render is not defined when applying a template update.
• The imported-type watch hook only invalidates clientCache, while server builds use serverCache. Changes to imported prop types can therefore leave the server using stale compiled results.

Would you be open to moving the server HMR changes into a separate PR? That would let us review the update behavior and add tests for actual SSR template and type updates independently.

@chenjiahan Oh, I didn't notice that! Of course - I've removed the HMR code.

I'll investigate both issues and bring them back in a separate PR. exposeModuleIdentifier stays in this one.

[chenjiahan]

LGTM 👍