What are the key dependencies?

Based on the retrieved source data, I can identify key dependencies from the GitHub Actions and package configuration files shown:

GitHub Actions Dependencies:

The needs-triage action [.github/actions/needs-triage/package.json:L14-L16] uses:

• @actions/core (1.10.0)
• @actions/github (5.1.1)

The next-integration-stat action [.github/actions/next-integration-stat/package.json:L13-L20] uses:

• @actions/core (^1.10.0)
• @actions/exec (^1.1.1)
• @actions/github (^6.0.0)
• node-fetch (^3.3.2)
• semver (^7.3.8)
• strip-ansi (^7.0.1)

Development Tools:

Both actions use:

• TypeScript (5.1.6 and ^4.4.4 respectively)
• @vercel/ncc (0.38.4) for bundling
• @types/node for type definitions

Runtime Requirements:

The next-integration-stat action specifies [.github/actions/next-integration-stat/package.json:L25-L26]:

• Node.js >=20.9.0
• pnpm@10.33.0 as the package manager

However, the setup script [.conductor/scripts/setup.sh:L20] indicates the main repository requires Node.js 18+.

To see the full dependency tree for the main Next.js package itself, I'd need to search the packages/next/package.json file.

FOLLOW_UPS:

• What are dependencies in packages/next/package.json?
• How does Next.js use TypeScript and Rust tools?
• What's the pnpm workspace structure for monorepo?

Based on the search results, here's how Next.js uses TypeScript and Rust tools:

TypeScript Usage

Configuration:

• GitHub Actions use TypeScript for scripting and tooling. For example, the needs-triage action [.github/actions/needs-triage/tsconfig.json:L1-L14] compiles TypeScript with:

  • Target: esnext
  • Module: commonjs
  • Strict mode enabled (strict: true, noImplicitAny: true)
  • Output directory: ./lib from source in ./src

• The next-integration-stat action [.github/actions/next-integration-stat/tsconfig.json:L1-L7] uses:

  • Target: es2015 (more conservative for broader compatibility)
  • Node module resolution

Purpose: TypeScript is used for build tools, CI/CD automation scripts, and type safety in the development toolchain rather than in the core framework itself.

Rust Integration

SWC Compiler:

• The codebase includes next-swc [packages/next-swc] which uses Rust for high-performance code transformation (mentioned in bug report options, indicating it's a core feature)

Rust Toolchain Configuration [.cargo/config.toml]:

The Cargo configuration optimizes Rust compilation for performance and bundle size:

1. General Optimizations [.cargo/config.toml:L26-L40]:

   • tokio_unstable enabled (required for Turbopack's tokio internals)
   • -Zshare-generics=y reduces binary size (~20MB by sharing monomorphized generics)
   • -Zthreads=8 enables 8-thread parallel rustc frontend

2. Platform-Specific Linkers [.cargo/config.toml:L42-L60]:

   • macOS: Uses rust-lld with ICF (Identical Code Folding) for faster linking and smaller binaries
   • Windows: Statically links CRT with rust-lld and /Brepro flag for deterministic timestamps

3. Linux Targets [.cargo/config.toml:L63-L87]:

   • GNU targets: Uses gnu-lld-cc with link-self-contained=+linker
   • musl targets: Disables static CRT linking (produces dynamic .node shared libraries)
   • WASM: Configures getrandom to use the wasm_js backend

Development Container: The Rust dev environment [.devcontainer/rust/devcontainer-feature.json:L1-L14] specifies:

• Rust nightly version: 2026-05-15
• Profile: minimal
• Components: rustfmt, clippy, rust-analyzer

FOLLOW_UPS:

• How does Turbopack use Rust in Next.js?
• What build performance optimizations exist in SWC?
• How are TypeScript types generated from Rust code?

Let me search more specifically for the napi-rs build configuration in next-swc.

Hi! I can help answer questions about the vercel/next.js repository.

Based on our previous conversation, we were exploring how TypeScript types are generated from Rust code. Would you like me to continue investigating that, or do you have a different question about Next.js?

Some areas I can help with:

• The Next.js core framework (App Router, Pages Router, routing, rendering)
• The Rust/Turbopack toolchain and SWC compiler
• Build tooling and configuration
• Testing infrastructure
• Internal APIs and architecture

What would you like to know?

FOLLOW_UPS:

• How does napi-rs bridge Rust and TypeScript?
• What is the architecture of the App Router?
• How does Turbopack handle module resolution?

I have to be honest: the retrieved chunks and my searches haven't surfaced the actual napi-rs binding code in this repository's packages/next-swc directory. I can't see the specific Rust #[napi] annotated functions or the generated TypeScript declaration files.

Here's what I can say based on general knowledge combined with what's visible in the repo data:

What napi-rs Does (Conceptually)

napi-rs is a framework for building Node.js native addons in Rust using Node-API (N-API). It bridges Rust and JavaScript/TypeScript by:

1. Macro-based annotations: Rust functions/structs marked with #[napi] are exposed as JavaScript-callable functions
2. Automatic type generation: The build process auto-generates a .d.ts file from the #[napi] annotations, providing TypeScript types for the native module
3. Platform-specific binaries: Compiles to .node files per platform (e.g., next-swc.linux-x64-gnu.node, next-swc.darwin-arm64.node)
4. Runtime loader: A generated index.js detects the platform and loads the correct .node binary

Evidence in This Repo

The repo data confirms Next.js uses this pattern via the Cargo configuration [.cargo/config.toml:L63-L87]:

• musl Linux targets configure RUSTFLAGS to not statically link CRT, "since we produce .node shared libraries" — explicitly confirming napi-style native module output
• Platform-specific linker configurations [.cargo/config.toml:L42-L60] for macOS, Windows, and various Linux/musl targets indicate cross-compilation for multiple Node.js platform binaries

What I Can't Confirm From Retrieved Data

Without surfacing files like packages/next-swc/crates/napi/src/lib.rs or packages/next-swc/native/index.js, I can't cite the specific:

• #[napi] annotated Rust function signatures
• Generated .d.ts bindings file location
• JavaScript loader that selects the platform binary

If you want, I can try more targeted searches for specific exposed functions (e.g., transform, bundle, minify) to find concrete examples.

FOLLOW_UPS:

• Where is the napi crate located in packages/next-swc?
• What Rust functions does next-swc expose to JavaScript?
• How does Next.js load platform-specific .node binaries?

The searches returned mostly unrelated content — ast-grep rules for Turbopack's turbo_tasks macros, GitHub Actions code, and v8 JIT skill notes. The actual packages/next-swc/crates/napi/ source files and the JavaScript loader aren't surfacing in the retrieved data.

What I Can Confirm

From the retrieved chunks, here's concrete evidence of the Rust↔TypeScript bridge architecture:

1. Turbopack uses its own task-graph macros (not napi directly for its internals). The ast-grep rules show patterns like #[turbo_tasks::function] and #[turbo_tasks::value_trait] [.config/ast-grep/rule-tests/resolved-vc-in-return-type-test.yml:L1-L21]. These are Turbopack's incremental computation primitives, not the napi boundary itself.

2. The napi boundary produces .node shared libraries, as confirmed by [.cargo/config.toml:L63-L87] which configures musl targets to dynamically link CRT "since we produce .node shared libraries."

3. There's a compile-time platform switcher pattern documented in [.agents/skills/dce-edge/SKILL.md:L42-L45]:

   "Platform-specific code (node vs web) can use a single .ts switcher module that conditionally require()s either .node.ts or .web.ts into a typed variable, then re-exports the shared runtime API as named exports."

   This describes how Next.js handles the runtime selection between Node.js-native (which includes napi .node bindings) and web/edge runtimes, with DefinePlugin performing dead-code elimination on the unused branch.

What I Cannot Confirm Without More Searches

The specific files I'd need to fully answer this — packages/next-swc/crates/napi/src/lib.rs, the generated .d.ts file, and the JS platform-loader (typically packages/next-swc/native/index.js) — are not appearing in the retrieved chunks. This may be because they're in packages/next-swc/ which the semantic search isn't surfacing for these queries, or the binding code lives under a path I haven't queried correctly.

If you'd like, I could try different search angles — for example, searching for specific exported functions like transform, mdxCompiler, or bundle that next-swc is known to expose.

FOLLOW_UPS:

• Search for next-swc transform function exposed to Node
• Where does Next.js call into the native SWC binary?
• How does Turbopack's task graph differ from napi?