Skip to content

fix(plugin): normalize workspace package import paths in metadata generator#3798

Open
maruthang wants to merge 1 commit intonestjs:masterfrom
maruthang:fix/issue-3453-plugin-metadata-import-paths
Open

fix(plugin): normalize workspace package import paths in metadata generator#3798
maruthang wants to merge 1 commit intonestjs:masterfrom
maruthang:fix/issue-3453-plugin-metadata-import-paths

Conversation

@maruthang
Copy link
Copy Markdown
Contributor

@maruthang maruthang commented Apr 2, 2026

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Other... Please describe:

What is the current behavior?

PluginMetadataGenerator (via ModelClassVisitor and ControllerClassVisitor) computes relative paths from the source directory to the physical node_modules/ location of workspace packages. This produces import paths like ../node_modules/@amk/utils/src/dto/order.dto in the generated metadata, which causes TypeScript TS2742 errors at compile time.

Issue Number: #3453

What is the new behavior?

A normalizePackagePath helper is extracted in plugin-utils.ts. It detects when a resolved path passes through node_modules/ and strips everything up to that boundary, returning a bare package specifier (e.g., @amk/utils/src/dto/order.dto). Both ModelClassVisitor and ControllerClassVisitor now use this helper in their collectedMetadata() methods, so generated metadata always contains correct importable package paths.

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

7 new unit tests added in test/plugin/normalize-package-path.spec.ts covering bare package paths, scoped packages, deep paths, and paths that should not be modified. All 152 tests pass.

@kamilmysliwiec
Copy link
Copy Markdown
Member

kamilmysliwiec commented Apr 9, 2026

You sure it won't break NestJS monorepo projects?

@kamilmysliwiec kamilmysliwiec mentioned this pull request Apr 9, 2026
Closed
4 tasks
@maruthang
Copy link
Copy Markdown
Contributor Author

maruthang commented Apr 9, 2026

Hi @kamilmysliwiec, great question! The normalizePackagePath helper only activates when the resolved path contains node_modules/ — it strips everything up to and including that segment to produce a bare package specifier (e.g., ../node_modules/@amk/utils/src/dto/order.dto → @amk/utils/src/dto/order.dto).

For intra-monorepo imports that resolve to relative paths (without going through node_modules/), the function returns the path unchanged — so existing NestJS monorepo projects should not be affected.

The new test suite covers both cases (scoped/unscoped workspace packages through node_modules, and plain relative paths that should pass through untouched). Happy to add more test scenarios if you'd like!

@kamilmysliwiec
Copy link
Copy Markdown
Member

kamilmysliwiec commented Apr 10, 2026

Could you resolve conflicts?

@maruthang maruthang force-pushed the fix/issue-3453-plugin-metadata-import-paths branch from 74b3160 to 478d8d5 Compare April 10, 2026 08:17
@maruthang
Copy link
Copy Markdown
Contributor Author

maruthang commented Apr 10, 2026

Hi @kamilmysliwiec, conflicts resolved! Rebased onto latest master — the only conflict was in plugin-utils.ts where both the safeDecodeURIComponent (from #3786) and normalizePackagePath functions were added at the same location. Both are preserved. All tests pass. Ready for review!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@maruthang @kamilmysliwiec