Summary

With bff.crossProject: true and declaration: true, consuming projects cannot resolve the generated <package>/api/* client types, failing with errors like:

error TS2307: Cannot find module '@shared/index' or its corresponding type declarations.

Two independent defects compound here:

1. Path aliases leak into every emitted declaration. compileByTs applies the tsconfig-paths transformer only as a before custom transformer, and TypeScript runs those solely on the JS emit — declaration emit keeps aliases exactly as authored (Alias for TypeScript declaration emitting microsoft/TypeScript#30952). So the emitted JS gets require("../shared/index") while the sibling .d.ts keeps from '@shared/index'.
2. The cross-project client copy breaks relative specifiers. clientGenerator copies each handler's declaration from dist/<lambda>/… into dist/client/… verbatim. The copy lands one directory shallower than its origin, so the relative specifiers TypeScript emitted for the origin (including inline import("…") types) no longer resolve from the copy.

Fix

Each defect is fixed in the layer that creates it:

• @modern-js/server-utils — the existing tsconfig-paths transformer now also runs on declaration emit (afterDeclarations), reusing the same path matcher. The declaration variant additionally handles inline import("…") types (ImportTypeNode), reads specifiers via .text (declaration nodes are synthesized without source positions, so getText() is unavailable), and keeps specifiers extensionless, matching tsc's own declaration output.
• @modern-js/plugin-bff — the client generator re-bases relative specifiers onto the copy's location at copy time, where the origin and destination of each file are both known.

Because both fixes live where dev and build converge, dev output is fixed as well, and no post-build processing step is needed.

Real output from the bff-corss-project integration fixture, before → after:

// dist/api/lambda/index.d.ts (origin)
import type { ApiMessage } from '@shared/index';        // before
import type { ApiMessage } from "../../shared/index";   // after

// dist/client/index.d.ts (generated client, one directory shallower)
import type { ApiMessage } from '@shared/index';        // before (verbatim copy)
import type { ApiMessage } from "../shared/index";      // after (re-based)

Bare package specifiers (e.g. import("@modern-js/plugin-bff/server")) are left untouched.

Behavior notes

All server-utils compile consumers (the BFF api compile and app-tools' server compile) now get alias-free declarations when declaration is enabled. The previously emitted aliased specifiers were unresolvable outside the project, and the JS emit already received the identical rewrite, so this is strictly a fix rather than a behavior change consumers could have relied on.

Test plan

• packages/server/utils/tests/ts.test.ts — new declaration-emit case: an aliased named import and an inline import("…") type are rewritten to relative specifiers; existing JS-emit cases unchanged.
• packages/cli/plugin-bff/tests/clientGenerator.test.ts — unit tests for specifier re-basing (from / import(…) / require(…) forms; bare specifiers untouched; no-op when origin and target match).
• tests/integration/bff-corss-project — bff-api-app now has an aliased type in a handler signature; a new prod-suite test walks every generated dist-1/client/**/*.d.ts, asserts no path alias leaks, and asserts every relative specifier resolves inside the dist tree.
• Verified locally: server-utils and plugin-bff unit suites plus the full bff client-app in prod integration describe are green.

Related Links

• Fixes [Bug]: BFF crossProject client .d.ts unresolvable for consumers (leaked path aliases + depth-shifted relative imports) #8739

Checklist

• I have added changeset via pnpm run change.
• I have updated the documentation. (N/A — bug fix, no API change)
• I have added tests to cover my changes.