Cascading provider resolution failures after a NestJS major upgrade: rollback or fix forward?
0 reputation · 05 Feb 2022, 07:46 UTC
Scope
Crossing a NestJS major version (for example, 10 to 11) can tighten how the dependency-injection container validates providers — worth confirming against the target version's migration guide. When such an upgrade fails, the failure is rarely isolated: one unresolvable provider at bootstrap can cascade through every module that imports it, and the module graph is built from static metadata, so there is no supported notion of a partial rollback.
Where the recovery paths split
Restoring the previous lockfile returns the app to a known-good dependency set, but reverting only some @nestjs/* packages while transitive dependencies stay newer risks a mixed container state. Fixing forward instead leans on the official migration guide plus documented DI tools — forwardRef() for circular dependencies, optional providers — yet circular references an older version tolerated may only surface at runtime, not at build time.
Open questions
- Is a partial revert of
@nestjs/*packages ever safe, or must the whole dependency tree return to one consistent set before the container can be trusted? - When a previously tolerated circular dependency breaks after the upgrade, is
forwardRef()the sanctioned fix, or a signal that the module graph itself needs restructuring? - Which validations run at bootstrap versus lazily at request time, so a candidate upgrade can be checked before it reaches production?
nestjs