feat(build): support copying library assets in monorepo builds

[maruthang]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features) — N/A, docs live in the separate nestjs/docs.nestjs.com repo and can be updated there once the API is finalized.

PR Type

What kind of change does this PR introduce?

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

Note: while this is shipped as an opt-in feature flag, it addresses a long-standing reported bug (#681, open since 2020) where library assets are silently dropped during monorepo app builds.

What is the current behavior?

Issue Number: 681

In a Nest monorepo, when you build an application project (nest build my-app), any assets configured on sibling library projects in nest-cli.json are silently dropped — only the app's own assets get copied to outDir. This forces consumers to either duplicate asset declarations on every app or work around it with custom build scripts.

What is the new behavior?

A new opt-in flag is introduced. When enabled, assets configured on library projects in the monorepo are copied to the building app's outDir alongside that app's own assets.

Two equivalent ways to enable it:

1. Per-project / global config in nest-cli.json:

   {
     "compilerOptions": {
       "includeLibraryAssets": true
     }
   }

2. CLI flag:

   nest build my-app --include-library-assets

Default behavior is unchanged — the flag is off by default, so existing monorepos see no difference.

Files changed

• actions/build.action.ts — read the new flag, merge library assets into the assets list passed to AssetsManager when enabled.
• commands/build.command.ts — register the --include-library-assets CLI option.
• lib/configuration/configuration.ts — add includeLibraryAssets?: boolean to CompilerOptions.
• lib/compiler/helpers/get-value-or-default.ts — recognize the new option for the standard config-resolution chain (CLI > project > root > default).
• test/actions/build.action.spec.ts — 7 new tests covering: flag off (default, no library assets copied), flag on via config, flag on via CLI, CLI override, no libraries case, multiple libraries, and library with no assets.
• test/lib/compiler/assets-manager.spec.ts — 3 new tests covering merging behavior in AssetsManager itself.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

The flag defaults to false, preserving the existing (broken-but-stable) behavior for everyone who hasn't explicitly opted in.

Other information

This implementation follows the proposal by @yogeshwaran-c in the #681 thread (April 2026). The proposal has not been explicitly acknowledged by maintainers in the thread, so the design is open for redirection — happy to rework if maintainers prefer a different approach, e.g.:

• Auto-detect library assets without a flag (would be a breaking change, hence why the proposal went opt-in).
• A different config shape (per-library opt-in, allowlist of library names, etc.).
• A different flag name or default location.

Closes #681

[kamilmysliwiec]

any chance we could remove this flag and just rely only on the nest-cli configuration?

[kamilmysliwiec]

Just checking if you're still interested in working on this PR