Should Node.js embrace a native, lightweight dependency injection pattern for large-scale applications?

[Kamakhya-s]

"Most backend ecosystems (like NestJS, Spring, or ASP.NET) have a core opinion on dependency injection for structuring large codebases, whereas Node.js core has historically left architecture entirely up to userland libraries.

As Node applications scale into massive microservices, we end up relying on fragmented third-party containers or manual wiring. Do you think Node.js should ever introduce a lightweight native primitive for service wiring, or does keeping it unopinionated remain its biggest strength?"

[k4hvecii]

I would probably keep dependency injection out of Node.js core, even for large applications.

One of Node.js's strengths is that the runtime does not impose an application architecture. The module system already gives us a natural boundary for composition, while the actual dependency wiring can remain explicit in application code.

The difficult part of adding DI to core would not be the container itself, but defining its semantics. For example:

singleton vs request/transient scopes
async factories and initialization
cleanup/disposal
circular dependencies
tokens vs classes vs symbols
ESM interoperability
test overrides and mocking
request-scoped dependencies

Once Node.js defines those behaviors, it effectively starts making architectural decisions that frameworks such as NestJS are currently free to make differently.

For many applications, a simple composition root is already enough:

const database = createDatabase(config)
const userRepository = createUserRepository(database)
const userService = createUserService(userRepository)
const app = createApp({ userService })

This is explicit, easy to test, has almost no magic, and works without a framework-specific container.

For very large systems, I can see value in Node.js providing lower-level primitives that DI libraries can build on, but I would prefer those primitives to stay generic rather than Node.js shipping an opinionated service container itself.

So my preference would be: keep DI in userland, but improve generic runtime primitives where large applications genuinely need them.