nft

Summary When a dependency's -resolved entry file is missing on disk (e.g. a package manager left a package directory in a torn state: from one version, from another), : 1. records a warning in (good), but 2. still emits the package's alone into , with no entry file and no marker of the failure. Deploying that file set produces a delayed, misleading runtime failure: Node finds the , resolves its map, and crashes with — a deep internal path that implicates the package rather than the trace/install. If nft emitted nothing for the package, the runtime error would at least be the legible . Reproduction (self-contained) Output (nft 1.10.2, Node 22): Copy to a deploy target and run there: Note the warning's full message already contains that exact path — the diagnostic exists at trace time, but nothing in the emitted file set reflects it. Real-world impact This is not hypothetical: we traced a production 500 on a Vercel serverless function to exactly this artifact shape — the deployed function filesystem contained 's 11.x but not the file its map resolves to, and every SSR request to the affected route failed with the deep above, via a runtime chain (). The build had succeeded with a green log (the consumer pipeline does not surface ). Diagnosing it took build-log forensics plus local reconstruction of the file-set shape; a visible trace-time diagnostic would have answered it immediately. There is also a fully self-contained Next.js-level reproduction (green , zero warnings, deployed standalone output 500s / silently drops page metadata): https://github.com/linyiru/next-silent-tracing-failure Suggestions (any subset would help) 1. When exports resolution fails because the target file does not exist, don't emit the bare for that package (or tag it in the result), so the shipped artifact fails legibly instead of pointing at the package's internals. 2. Offer an opt-in strict mode (e.g. ) so CI/builders can hard-fail on this class of trace failure. 3. At minimum, document that may contain -only entries for packages whose resolution failed, and that consumers should surface — the major consumers (Next.js output file tracing, the Vercel builder) currently swallow them. Environment: 1.10.2, Node.js 22.22, macOS/Linux (reproduced on both).

Summary resolve import/export wildcard patterns that include a trailer, such as match both the pattern prefix and trailer before substituting the captured wildcard use Node-compatible pattern precedence and reject patterns containing multiple wildcards add an trace fixture covering mapped through Context NFT previously recognized wildcard keys only when they ended in . A valid import map such as: therefore failed to resolve . Consumers such as Nitro/nf3 would trace the package entry point but omit the internal target, producing an incomplete deployment artifact that failed at runtime with . Related reproduction and downstream workaround: https://github.com/cmpadden/eve-repro-nitro-wildcard-package-imports https://github.com/vercel/eve/pull/1181 Regression testing The new fixture imports and expects in the trace. Before this change, both the cwd-based and root-based fixture variants failed because the marker file was absent. After the resolver change, both variants pass. Validation performed: — 1,475 tests passed

Whether a package's export target is traced depends on the Node.js version running ( in ), not on what supported runtimes resolve. Node's CJS loader matches from 20.19, so every Node 20.x build (including latest 20.20.2) omits a file that even its own runtime resolves — pruned output crashes with with no build/deploy version skew at all. Minimal repro: https://github.com/timfish/repro-nft-module-sync — fails on Node 20.x, passes on Node 22; and the trace disagree within a single process. Related: the wildcard-exports branch from #584 has the mirror problem — on Node >= 22 it emits only the target (fallback gated on , default ), breaking older deploy runtimes. Possible directions — happy to PR whichever you prefer: 1. Default to (#584 already emits both targets behind it) 2. Drop the version gates and always dual-emit 3. Correct the version check ( → also 20.19+) — still leaves build-vs-deploy version skew unsound Seen in the wild via : Nitro server bundles (nuxt/solidstart/tanstack prod servers crash at boot) and AWS Lambda layers built on Node 20.