Support Symbol as Dependency Identifier

[l246804]

Is your feature request related to a problem? Please describe

I'm developing an SDK library that needs to provide built-in classes, but I want to use Symbol variables as dependency identifiers when registering them externally. Currently, the library only supports string names for dependencies, which can lead to naming conflicts with other modules that might use the same string identifiers.

Describe the solution you'd like

I'd like the dependency injection/system to support Symbol variables as valid dependency names/identifiers. Symbols are guaranteed to be unique and would perfectly solve the naming collision problem in modular applications.

For example:

// refer vue3 InjectionKey
interface ModuleConstraint<T> {}

type ModuleKey<T> = symbol & ModuleConstraint<T>

class Router {
  toggle() {
    // ...
  }
}

const ROUTER_ID: ModuleKey<Router> = Symbol('router')

const sdk = new Injector([
  {
    [ROUTER_ID]: ['type', Router]
  }
])

// a typed instance of a component
const router = sdk.get(ROUTER_ID)
router.toggle()

Describe alternatives you've considered

1. Using UUIDs or long random strings as names - but this is less elegant and still has (extremely small) potential for conflicts

2. Using namespaced strings (e.g., 'my-sdk:dependency-name') - better but still not as foolproof as Symbols

3. Maintaining a separate dependency container just for my SDK - which would complicate usage for end users

Additional context

This is particularly important for SDKs/libraries that need to coexist in applications with other third-party code. Symbols would provide a clean, conflict-free way to identify dependencies. Many modern JavaScript APIs (like Vue 3's injection system) already support Symbols for this purpose.

[nikku]

@l246804 Thanks for opening this feature request.

In addition to your sketched alternatives didi supports private modules.

To advance with your proposal we'd need a set of test cases to verify desired uses of "symbols as identifiers", not only for external use (you sketched in your description), but also for use of "dependency injection":

function MyComponent(foo, bar) {

  // I get <foo> and <bar> from somewhere
}

If we find a suitable way to hook in foo and bar identified via symbols, then this could be a nice evolution of the existing library.