Custom error classes exported

When every error a package throws is a plain Error with a string message, consumers are forced to parse error messages with regex or includes() checks — fragile code that breaks the moment you change wording. ISO 25010 fault-tolerance and testability both suffer: you cannot write a catch (e) { if (e instanceof NetworkError) guard without custom error types. For SDK packages that wrap external APIs, distinguishing a 429 from a 500 from a network timeout requires typed errors. Without them, consumers either swallow all errors or crash on recoverable conditions.

Define and export a typed error hierarchy from src/errors.ts, then re-export it from your package entry point.

// src/errors.ts
export class SdkError extends Error {
  constructor(message: string, public readonly code: string) {
    super(message)
    this.name = 'SdkError'
  }
}

export class ApiError extends SdkError {
  constructor(message: string, public readonly statusCode: number) {
    super(message, 'API_ERROR')
    this.name = 'ApiError'
  }
}

export class RateLimitError extends ApiError {
  constructor(public readonly retryAfter: number) {
    super('Rate limit exceeded', 429)
    this.name = 'RateLimitError'
  }
}

// src/index.ts
export { SdkError, ApiError, RateLimitError } from './errors'

Consumers can then guard: if (e instanceof RateLimitError) { await sleep(e.retryAfter * 1000) }.