Blog
Engineering notes on how TinyDI was actually designed and built — real trade-offs, real dead ends, no marketing.
What the release plan couldn't predict: publishing for real
The npm package name getting blocked at the actual publish moment, the OTP/CI standoff that followed, and a handful of docs-app bugs only production traffic (or a real browser) revealed.
Why no reflect-metadata
The "explicit over magic" call behind TinyDI: what reflection-based DI buys you, what it costs, and why we wired dependencies by hand instead.
Designing type-safe tokens without explicit generics
How createToken
Detecting circular dependencies
How TinyDI catches A -> B -> C -> A at resolution time with a simple resolution-path stack, and why the error message format was designed the way it is.
An error hierarchy, instead of throw new Error(...)
Why TinyDI has ContainerError, RegistrationError, ResolutionError and CircularDependencyError instead of one generic error type, and what that decision actually implied.
What we haven't built yet (and why)
Scoped lifetimes, child containers, async resolution and plugins are not in TinyDI today — a deliberate minimalism, not an oversight, and what it would take to add each one.
Building a documentation site without a framework
Why this site is a hand-written Node static-site generator instead of 11ty/Astro/Next, and three real bugs that only showed up in an actual browser.
Preparing TinyDI for npm: package.json, the exports map, and tree-shaking
What actually publishing a zero-dependency ESM/CJS library involves: a dual-package build with tsup, a double-condition exports map, and a build-tool quirk that wasn’t ours to fix.