Why vapor component getCurrentInstance return null?

[xuyimingwork]

This behavior will break so many tools in vue & Why there is a vapor shape instance but still just return null?

[barry166]

Yes, this is expected for Vapor right now, not a missing lifecycle instance. Vapor has its own internal instance shape, but it is not the same classic VNode/runtime-core instance that existing getCurrentInstance() consumers usually inspect; exposing it through the old API would make many non-public fields look supported when they are not.

For app and library code, the safer migration path is to move off getCurrentInstance() and use public APIs instead: provide/inject, lifecycle hooks, useAttrs/useSlots, defineExpose/template refs, etc. If a tool genuinely depends on internals, it will need a Vapor-aware branch because the instance shape is different. There was an earlier discussion about the same compatibility issue here: https://github.com/orgs/vuejs/discussions/13629

[xuyimingwork]

Yes, this is expected for Vapor right now, not a missing lifecycle instance. Vapor has its own internal instance shape, but it is not the same classic VNode/runtime-core instance that existing getCurrentInstance() consumers usually inspect; exposing it through the old API would make many non-public fields look supported when they are not.

For app and library code, the safer migration path is to move off getCurrentInstance() and use public APIs instead: provide/inject, lifecycle hooks, useAttrs/useSlots, defineExpose/template refs, etc. If a tool genuinely depends on internals, it will need a Vapor-aware branch because the instance shape is different. There was an earlier discussion about the same compatibility issue here: github.com/orgs/vuejs/discussions/13629

Thanks for the explanation @barry166 !

I totally understand that Vapor uses a different instance shape (GenericComponentInstance) and doesn't rely on ComponentInternalInstance or the VNode/render-tree architecture.

However, my primary concern isn't about inspecting render tree or VNode internals—it's about accessing essential component context metadata. A component instance carries crucial state such as appContext (for app-level configs/plugins), parent hierarchy, and instance-level provides.

By returning null entirely, these contextual properties become completely inaccessible inside Vapor components. This leaves ecosystem libraries, devtools, and advanced utilities with no supported way to inspect or tap into the current component's context, even when they don't care about VNodes at all.

If getCurrentInstance() is intentionally kept for ComponentInternalInstance to avoid exposing legacy internals, is there a plan to export a public/unified generic accessor (or context API) that provides access to shared metadata like appContext, parent, and provides across both Vapor and standard components?

[lMysticl]

There is a Vapor instance, but it is deliberately not a ComponentInternalInstance.

On the Vapor branch, Vue keeps a GenericComponentInstance and the internal getCurrentGenericInstance() returns it. The exported getCurrentInstance() is still typed as ComponentInternalInstance, and that interface explicitly excludes Vapor, so Vapor instances are filtered out and the function returns null.

So this is an API boundary, not a missing lifecycle context. Libraries should use public APIs such as inject, lifecycle hooks, useAttrs, useSlots, or template refs. A tool that genuinely needs instance internals needs a Vapor-specific adapter; there is currently no public generic-instance replacement.

[xuyimingwork]

There is a Vapor instance, but it is deliberately not a ComponentInternalInstance.

On the Vapor branch, Vue keeps a GenericComponentInstance and the internal getCurrentGenericInstance() returns it. The exported getCurrentInstance() is still typed as ComponentInternalInstance, and that interface explicitly excludes Vapor, so Vapor instances are filtered out and the function returns null.

So this is an API boundary, not a missing lifecycle context. Libraries should use public APIs such as inject, lifecycle hooks, useAttrs, useSlots, or template refs. A tool that genuinely needs instance internals needs a Vapor-specific adapter; there is currently no public generic-instance replacement.

Thanks for the explanation @lMysticl !

I totally understand that Vapor uses a different instance shape (GenericComponentInstance) and doesn't rely on ComponentInternalInstance or the VNode/render-tree architecture.

However, my primary concern isn't about inspecting render tree or VNode internals—it's about accessing essential component context metadata. A component instance carries crucial state such as appContext (for app-level configs/plugins), parent hierarchy, and instance-level provides.

By returning null entirely, these contextual properties become completely inaccessible inside Vapor components. This leaves ecosystem libraries, devtools, and advanced utilities with no supported way to inspect or tap into the current component's context, even when they don't care about VNodes at all.

If getCurrentInstance() is intentionally kept for ComponentInternalInstance to avoid exposing legacy internals, is there a plan to export a public/unified generic accessor (or context API) that provides access to shared metadata like appContext, parent, and provides across both Vapor and standard components?

[xuyimingwork]

Changing the internal shape shouldn't be equated to erasing the API's foundational capability. Object shape and API availability are two entirely different concepts.

Even if Vapor alters the rendering infrastructure, the core identity of a component instance as a "context carrier" remains unchanged. Properties like appContext, parent, and provides are universal concepts shared by both paradigms.

Returning null simply because the rendering fields differ feels like leaking internal implementation details to the public boundary. Instead of a hard cut, wouldn't it make more sense to expose a unified, polymorphic interface that safely provides access to these common context fields?

Furthermore, if the intention behind returning null is to protect users from relying on a mismatching object shape and getting runtime errors, returning null is actually a worse and more misleading error.

Returning null explicitly signals to the ecosystem that "there is no active component context at all," which is factually incorrect—the Vapor component is actively running.

If a library attempts to read a legacy field from a Vapor instance, it yields a clear, local error (e.g., Cannot read property of undefined), which immediately signals a shape mismatch. However, returning null completely misleads the library into thinking it's being executed outside of a component lifecycle entirely, causing unnecessary shield crashes and hiding the real core metadata (appContext, parent, provides) that is actually there.

Preventing a shape mismatch shouldn't mean faking the absence of the entire context.

[xuyimingwork]

see: #13687 (comment)