What problem does this solve?
Linearis currently depends on @linear/sdk even though the codebase already has generated GraphQL operations, a GraphQLClient, and direct GraphQL usage for most business logic. The SDK is only used as a GraphQL transport wrapper and as a convenience facade for resolver lookups.
This keeps two API-client contracts in the architecture (ctx.gql and ctx.sdk), forces documented resolver exceptions, adds a large production dependency, and makes dependency/version drift harder to reason about.
Proposed solution
Track the staged removal of @linear/sdk without losing functionality:
- Replace the SDK-backed GraphQL transport with native Node 22
fetch.
- Add missing GraphQL lookup operations needed by resolvers.
- Migrate resolvers from
LinearSdkClient to GraphQLClient.
- Remove
LinearSdkClient, ctx.sdk, and the package dependency.
This parent issue should own the dependency-removal initiative. Child issues should remain independently reviewable and preserve current resolver behavior unless a behavior change is explicitly scoped.
Alternatives considered
- Keep the SDK and only update it: lower short-term risk, but keeps the split-client architecture and dependency weight.
- Replace only resolver usage: still leaves SDK in
GraphQLClient, so the dependency cannot be removed.
- Big-bang removal: possible, but too broad and risky for review.
Primary use case
Shell scripting / automation
Additional context
Audit summary:
- Direct SDK imports exist in:
src/client/graphql-client.tssrc/client/linear-client.tssrc/resolvers/status-resolver.tssrc/resolvers/cycle-resolver.ts
- SDK runtime calls are resolver lookups like
teams, users, issues, projects, projectLabels, issueLabels, workflowStates, cycles, and initiatives.
- Existing generated GraphQL types can replace SDK filter types, including
CycleFilter, WorkflowStateFilter, TeamFilter, UserFilter, ProjectFilter, IssueLabelFilter, ProjectLabelFilter, and InitiativeFilter.
graphql must become a direct pinned production dependency if runtime print() usage remains after SDK removal.
What problem does this solve?
Linearis currently depends on
@linear/sdkeven though the codebase already has generated GraphQL operations, aGraphQLClient, and direct GraphQL usage for most business logic. The SDK is only used as a GraphQL transport wrapper and as a convenience facade for resolver lookups.This keeps two API-client contracts in the architecture (
ctx.gqlandctx.sdk), forces documented resolver exceptions, adds a large production dependency, and makes dependency/version drift harder to reason about.Proposed solution
Track the staged removal of
@linear/sdkwithout losing functionality:fetch.LinearSdkClienttoGraphQLClient.LinearSdkClient,ctx.sdk, and the package dependency.This parent issue should own the dependency-removal initiative. Child issues should remain independently reviewable and preserve current resolver behavior unless a behavior change is explicitly scoped.
Alternatives considered
GraphQLClient, so the dependency cannot be removed.Primary use case
Shell scripting / automation
Additional context
Audit summary:
src/client/graphql-client.tssrc/client/linear-client.tssrc/resolvers/status-resolver.tssrc/resolvers/cycle-resolver.tsteams,users,issues,projects,projectLabels,issueLabels,workflowStates,cycles, andinitiatives.CycleFilter,WorkflowStateFilter,TeamFilter,UserFilter,ProjectFilter,IssueLabelFilter,ProjectLabelFilter, andInitiativeFilter.graphqlmust become a direct pinned production dependency if runtimeprint()usage remains after SDK removal.