FAQ

No, by design. You wire up constructor arguments yourself inside a factory ((c) => new UserService(c.resolve(UserRepositoryToken))). This is the core trade-off TinyDI makes: more explicit code, no reflection.

Not directly — a second registration on an already-registered token throws RegistrationError. Call container.remove(token) first (or container.clear() to reset everything), then register again. This is useful for swapping implementations in tests.

Not in this version — only Singleton and Transient exist today. The design intentionally doesn't preclude adding a scoped lifetime later, but it isn't part of the current API.

Not in this version. Each Container is fully self-contained with no shared global state, which leaves the door open for a parent/child relationship in a future version without requiring a redesign.

No — it has zero runtime dependencies and uses no Node-specific APIs, so it runs unmodified on Bun, Deno and in the browser.

Factory<T> is synchronous by design ((container: Container) => T). If you need to build something asynchronously, resolve a promise-returning value as the service itself (Token<Promise<T>>) and await it at the call site — TinyDI does not currently ship a dedicated async resolution API.