.

[jayeshk717]

Context
I'm working on library component which needs to render a link component according to the runtime in which it is being used like in Vue app, Nuxt app or storybook.

I used getCurrentInstance()!.appContext.config.globalPropertiesgetCurrentInstance().appContext.config.globalProperties to get the router instance but I gone through a couple of discussions threads on github which states that this should not be used.

I also saw a couple of references in other vue libraries to be using this for e.g. in element-plus https://github.com/element-plus/element-plus/blob/4984d1b01410e045424dfaa668a0ce59bfaa70d7/packages/components/menu/src/menu.ts#L197

When looked Inside code it has been mentioned that it has been exported for advanced usage and not marked as internal ref -

core/packages/runtime-core/src/index.ts

Line 102 in 928af5f

// For getting a hold of the internal instance in setup() - useful for advanced

core/packages/runtime-core/src/component.ts

Line 312 in 928af5f

* We expose a subset of properties on the internal instance as they are

Given my scenario please help me to clarify whether I can rely on getCurrentInstance()!.appContext.config.globalProperties or any other property like getCurrentInstance().proxy mentioned here vuejs/vue#12596 (comment)?

If not then how can I access global properties inside composition setup? Please help me to get the correct solution 🙏 🙏 🙏

Let me know if anything else needs to be clarified by my side. Thanks in advance!

[jh-leong]

You might find this related discussion helpful: #11486.

[jh-leong]

Sorry for the delay @jayeshk717 .

As Evan mentioned in vuejs/vue#12596 (comment):

We exposed getCurrentInstance mostly for official libraries that need additional internal access, not for userland application code.

If you do choose to use getCurrentInstance in your library, it should be used sparingly and with caution, as it comes with its own risks.

[jh-leong]

Yes, it still works in Vue 3.4+.

[jh-leong]

It's understandable to want to keep things simple. Using this for your specific use case should be fine as long as you're aware of the potential risks. Just keep in mind that since it's not part of the public API, there might be changes in the future that could affect its behavior.

If stability is a concern, you might want to consider alternative approaches or ensure you have fallback options in place.

[jayeshk717]

Okay, noted. Thanks