Phase 11: Dependencies Analysis

Complete dependency audit of the copilot-sdk multi-language monorepo. Every runtime, dev, and cross-cutting dependency is catalogued with version constraints, purpose, and risk posture.

1. Runtime Dependencies Per SDK

1.1 Node.js SDK TypeScript

Source: nodejs/package.json

1.2 Python SDK Python

Source: python/pyproject.toml

1.3 Go SDK Go

Source: go/go.mod

Indirect Go dependencies (from go/go.sum):

1.4 .NET SDK .NET

Source: dotnet/src/GitHub.Copilot.SDK.csproj + dotnet/Directory.Packages.props

2. Dev Dependencies Per SDK

2.1 Node.js SDK TypeScript

Source: nodejs/package.json

2.2 Python SDK Python

Source: python/pyproject.toml

2.3 Go SDK Go

No explicit dev dependencies in go.mod. Go uses the standard go test toolchain. The google/go-cmp in go.sum is an indirect dependency.

2.4 .NET SDK .NET

Source: dotnet/test/GitHub.Copilot.SDK.Test.csproj + dotnet/Directory.Packages.props

3. Shared / Cross-cutting Dependencies

3.1 Code Generation Toolchain

Source: scripts/codegen/package.json

3.2 Test Harness

Source: test/harness/package.json

3.3 Cross-SDK Dependency Matrix

4. Dependency Tree Depth

flowchart LR
  A["<b>3</b><br/>Node.js Runtime Deps"] ~~~ B["<b>2</b><br/>Python Runtime Deps"] ~~~ C["<b>3</b><br/>Go Direct Deps"] ~~~ D["<b>5</b><br/>.NET Package Refs"]
          

4.1 Node.js SDK -- Moderate Depth

The dependency tree has two layers of concern:

• Shallow direct deps: The SDK declares only 3 runtime dependencies. The code itself (nodejs/src/) imports only from vscode-jsonrpc/node.js and @github/copilot at runtime. zod is not imported in source -- it is a peer-like dependency consumed by SDK users for tool definitions.
• Deep transitive tree via @github/copilot: This package bundles platform-specific native binaries via 6 optional dependencies (@github/copilot-darwin-arm64, @github/copilot-darwin-x64, @github/copilot-linux-arm64, @github/copilot-linux-x64, @github/copilot-win32-arm64, @github/copilot-win32-x64). These are leaf packages with no further transitive dependencies.
• Dev dependency depth: eslint, vitest, and quicktype-core each bring large transitive trees, but these are not shipped.

4.2 Python SDK -- Very Shallow

Only 2 runtime dependencies. pydantic has its own dependency tree (pydantic-core, typing-extensions, annotated-types), but this is standard and well-understood.

4.3 Go SDK -- Very Shallow

Only 3 direct dependencies with 1 indirect (go-cmp). The go.sum file is only 8 lines, confirming a remarkably flat dependency graph.

4.4 .NET SDK -- Shallow

5 package references, all from Microsoft. The PrivateAssets="compile" on StreamJsonRpc means it is internalized at build time, reducing the transitive surface for consumers.

5. Key Dependency Analysis

5.1 @github/copilot -- The Copilot CLI Binary Package

What it is: A first-party GitHub npm package that bundles the Copilot CLI as platform-specific native binaries distributed through optional dependencies. It follows the same pattern as esbuild, turbo, and other native-binary npm packages.

What it provides:

• Native CLI binary via platform packages (@github/copilot-{os}-{arch}), loaded through npm-loader.js
• JavaScript entry point (index.js) that the SDK resolves and spawns as a Node.js child process
• SDK integration point (sdk/index.js) used by CopilotClient.getBundledCliPath() to locate the CLI
• JSON Schema definitions (schemas/api.schema.json, schemas/session-events.schema.json) consumed by the codegen toolchain to generate typed RPC bindings for all four SDKs

How the Node.js SDK uses it (from nodejs/src/client.ts:88-99):

function getBundledCliPath(): string {
    const sdkUrl = import.meta.resolve("@github/copilot/sdk");
    const sdkPath = fileURLToPath(sdkUrl);
    return join(dirname(dirname(sdkPath)), "index.js");
}

How codegen uses it (from scripts/codegen/utils.ts:29-46):

// Resolves schemas from the installed @github/copilot package
const schemaPath = path.join(
    REPO_ROOT,
    "nodejs/node_modules/@github/copilot/schemas/session-events.schema.json"
);

5.2 vscode-jsonrpc -- JSON-RPC Protocol Layer

What it is: Microsoft's JSON-RPC 2.0 implementation, originally built for the Language Server Protocol (LSP) in VS Code. Published under the vscode-languageserver family of packages.

What the SDK uses from it (from nodejs/src/client.ts:20-25 and nodejs/src/session.ts:10-11):

• createMessageConnection -- creates a bidirectional JSON-RPC connection over streams
• StreamMessageReader / StreamMessageWriter -- stream-based message framing (stdio or TCP)
• MessageConnection -- the connection type for sending requests/notifications
• ResponseError / ConnectionError -- typed error classes for RPC failures

Why it matters: This is the core transport abstraction. The entire Node.js SDK communicates with the Copilot CLI through this library. The ^8.2.1 version constraint pins to the v8.x line which is the current stable release. The .NET SDK uses the equivalent Microsoft library StreamJsonRpc (same team, same protocol, different runtime).

5.3 zod -- Schema Validation (Tool Parameters)

What it is: Zod is a TypeScript-first schema declaration and validation library. Version 4.x introduces toJSONSchema() as a native method.

How the SDK uses it: Zod is NOT directly imported in the SDK source code. Instead, the SDK defines a ZodSchema interface (nodejs/src/types.ts:148-151) that any object with a toJSONSchema() method satisfies:

export interface ZodSchema<T = unknown> {
    _output: T;
    toJSONSchema(): Record<string, unknown>;
}

The SDK checks for this interface at runtime (nodejs/src/client.ts:61-68):

function isZodSchema(value: unknown): value is { toJSONSchema(): Record<string, unknown> } {
    return (
        value != null &&
        typeof value === "object" &&
        "toJSONSchema" in value &&
        typeof (value as { toJSONSchema: unknown }).toJSONSchema === "function"
    );
}

6. Version Constraints

6.1 Strategy by Ecosystem

6.2 Notable Version Constraint Decisions

Pre-release pinning on @github/copilot

^1.0.3-0 in nodejs/package.json:47 -- the -0 suffix indicates a pre-release tag. The caret range with a pre-release means npm will only resolve to >=1.0.3-0 <2.0.0 for pre-release versions of 1.0.3, and any stable >=1.0.3.

.NET Central Package Management

dotnet/Directory.Packages.props:4 sets ManagePackageVersionsCentrally=true, meaning individual .csproj files cannot specify versions -- they are all controlled from this single file. This ensures version consistency across src and test projects.

Python's permissive floors

pydantic>=2.0 (python/pyproject.toml:27) allows any Pydantic 2.x release. This is intentionally broad to avoid conflicts with user applications that may pin specific Pydantic versions.

Node.js engine constraint

"node": ">=20.0.0" (nodejs/package.json:69) -- enforces a minimum Node.js 20 requirement. This corresponds to Node.js 20 LTS.

6.3 Pinned vs Range Summary

7. Dependency Update Strategy

7.1 Dependabot Configuration

Source: /.github/dependabot.yaml

The repository uses Dependabot v2 with weekly updates and a multi-ecosystem group strategy.

multi-ecosystem-groups:
  all:
    schedule:
      interval: 'weekly'

Monitored ecosystems:

7.2 Update Flow Analysis

Grouped PRs: The multi-ecosystem-group: all with patterns: ['*'] means Dependabot will attempt to group ALL dependency updates across ALL ecosystems into a single weekly PR. This reduces PR noise but means a failure in one ecosystem can block updates in others.

7.3 NuGet Source Configuration

<packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
<packageSourceMapping>
    <packageSource key="nuget.org">
        <package pattern="*" />
    </packageSource>
</packageSourceMapping>

8. Internal Dependencies

8.1 Codegen Pipeline

The code generation toolchain is the central connective tissue of the monorepo. It lives at scripts/codegen/ and generates typed bindings for all four SDKs from the JSON Schema files bundled inside @github/copilot.

Dependency chain:

flowchart TD
  A["@github/copilot\n(npm package)"] --> S1["schemas/api.schema.json"]
  A --> S2["schemas/session-events.schema.json"]
  S1 --> B["scripts/codegen/\n(Node.js toolchain)"]
  S2 --> B
  B --> C["typescript.ts\nnodejs/src/generated/rpc.ts"]
  B --> D["csharp.ts\ndotnet/src/Generated/"]
  B --> E["python.ts\npython/copilot/generated/"]
  B --> F["go.ts\ngo/generated/"]
          

8.2 .NET SDK's Cross-Ecosystem Dependency

The .NET build extracts the Copilot CLI version from the Node.js lockfile:

<Exec Command="node -e &quot;console.log(require('./nodejs/package-lock.json')
    .packages['node_modules/@github/copilot'].version)&quot;"
    WorkingDirectory="$(MSBuildThisFileDirectory)../.." />

This means the .NET SDK build requires:

• Node.js to be installed on the build machine
• The nodejs/package-lock.json to exist and contain the resolved @github/copilot version
• This version is written to a .props file and shipped in the NuGet package

8.3 Test Harness

The test harness at test/harness/ is an independent Node.js project with its own package.json. It is NOT published and serves as cross-SDK integration test infrastructure.

• Uses its own copy of @github/copilot (version ^0.0.421 -- significantly older than the SDK's ^1.0.3-0)
• Brings in @modelcontextprotocol/sdk and openai for testing MCP and AI interactions
• Shares vitest and tsx with the main Node.js SDK

9. Platform Requirements

9.1 Minimum Versions

9.2 Supported Python Versions

Explicitly classified for Python 3.11, 3.12, 3.13, and 3.14.

9.3 .NET Build Requirements

• AOT Compatible: IsAotCompatible=true (dotnet/src/GitHub.Copilot.SDK.csproj:16)
• Nullable reference types: enabled (dotnet/Directory.Build.props:7)
• Warnings as errors: enabled (dotnet/Directory.Build.props:9)
• Reflection-free JSON: Test project disables reflection-based serialization to validate NativeAOT compatibility (dotnet/test/GitHub.Copilot.SDK.Test.csproj:14)

9.4 Node.js SDK Module System

The Node.js SDK is an ESM-only package ("type": "module" at nodejs/package.json:22). It provides dual exports:

• . (main): ./dist/index.js with types at ./dist/index.d.ts
• ./extension: ./dist/extension.js with types at ./dist/extension.d.ts

9.5 Copilot CLI Platform Binaries

The @github/copilot package supports 6 platform targets via optional dependencies:

10. Potential Risks

10.1 Version Divergence: @github/copilot Between SDK and Harness

10.2 Pre-release Dependency on Core Package

10.3 Codegen Not Monitored by Dependabot

10.4 Zod v4 -- Bleeding Edge

10.5 Cross-Ecosystem Build Dependency

10.6 Single-Maintainer Risk Assessment

10.7 Python Version Floor Permissiveness

pydantic>=2.0 allows installing Pydantic 2.0.0 through the latest. Early Pydantic 2.x releases had breaking changes and bugs. A tighter floor (e.g., >=2.7) would be safer.

Similarly, python-dateutil>=2.9.0.post0 is very specific for the floor (a post-release version), which is appropriate.

10.8 No Lock File for Python

10.9 Go Version Requirement

Go 1.24 (go/go.mod:3) is quite recent. Users on older Go versions (1.22, 1.23) will be unable to use the SDK.

Appendix: Complete Dependency Count Summary

flowchart LR
  A["<b>~49</b><br/>Total Unique Dependencies"] ~~~ B["<b>13</b><br/>Runtime Dependencies"] ~~~ C["<b>25</b><br/>Dev Dependencies"] ~~~ D["<b>11</b><br/>Shared / Tooling"]
          

The repository maintains a lean dependency footprint across all four SDKs, with the heaviest dependency surface being in the Node.js SDK and its associated build tooling.