Skip to content

Import NestJS statically in specs so NestJS 12 boots one copy of it - #148

Merged
rodrigobnogueira merged 1 commit into
mainfrom
fix/static-nest-imports-in-specs
Oct 26, 2026
Merged

rodrigobnogueira merged 1 commit into
mainfrom
fix/static-nest-imports-in-specs

Conversation

@rodrigobnogueira

Copy link
Copy Markdown
Contributor

Summary

  • Fixes the root cause behind the red NestJS 12 group (chore(deps)(deps): Bump the nest-stack group across 1 directory with 5 updates #139): five integration specs loaded @nestjs/common, @nestjs/core and @nestjs/drizzle with import() inside before(). NestJS 12 ships core and common as ESM-only, and under node --import tsx an import() of an ESM-only package loads a second copy next to the one src/ requires. The specs' NestFactory then registered a different HttpAdapterHost class from the one nestjs-cls's ClsRootModule injects, so every non-HTTP boot failed with "Nest can't resolve dependencies of the ClsRootModule (?, ModuleRef)".
  • Static imports change nothing on NestJS 11. This is the third two-copies failure, after nestjs-cls and @nestjs/outbox, so the rule and its enforcement land here too.

Changes

  • test/integration/{kafka-consumer-inmemory,kafka-request-reply-inmemory,rabbit-inbox,reliable-messaging.kafka,reliable-messaging.rabbitmq}.spec.ts: the @nestjs/* imports move from before() to the top of the file. Our own env-reading modules stay dynamic.
  • scripts/check-static-imports.mjs, run by npm run lint: fails on any import() of @nestjs/*, @nestjs-cls/* or nestjs-cls in src/, test/ and scripts/. On the unfixed tree it reports exactly the 13 removed calls.
  • GUIDELINES_NEST_REFERENCE_APP.md §7 states the rule ("When In Doubt" becomes §8). CHANGELOG.md entry under Unreleased.

Modules Touched

  • Tooling / CI / docs only

Public Surface (libraries)

  • No use of library internals introduced
  • Roster unchanged, or the roster checklist was followed (README,
    package.json description, docs/, repo About — npm run docs:check)

Security Review

  • No unresolved high-risk security finding remains (test and tooling change)

Dependency Review

  • No dependency or lockfile changes

Migrations

  • No schema changes

Validation

  • git diff --check
  • npm run typecheck
  • npm run lint
  • npm run test:cov
  • npm run security:audit

Validation Notes

Release Notes

  • Release impact: CHANGELOG.md updated

Five integration specs loaded @nestjs/common, @nestjs/core and
@nestjs/drizzle with import() inside before(). NestJS 12 ships core and
common as ESM-only, and under tsx an import() of an ESM-only package
loads a second copy next to the one src/ requires. The specs' NestFactory
then registered a different HttpAdapterHost class from the one
nestjs-cls's ClsRootModule injects, so every non-HTTP boot failed with
"Nest can't resolve dependencies of the ClsRootModule". That is what
kept the NestJS 12 Dependabot group red. Static imports change nothing
on NestJS 11.

This is the third two-copies failure, after nestjs-cls and
@nestjs/outbox, so GUIDELINES section 7 states the rule and npm run lint
enforces it: scripts/check-static-imports.mjs fails on any import() of
@nestjs/*, @nestjs-cls/* or nestjs-cls in src/, test/ and scripts/.
@rodrigobnogueira
rodrigobnogueira merged commit 8287df2 into main Oct 26, 2026
3 checks passed
@rodrigobnogueira
rodrigobnogueira deleted the fix/static-nest-imports-in-specs branch October 26, 2026 02:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant