阅读中文版本

TypeScript TS1086 — Accessor Cannot Be Declared in Ambient Context

Fix TS1086 by converting interface or declaration accessors to plain properties, since ambient and interface contexts cannot contain get/set bodies.

npx tsc --noEmit 2>&1 | grep TS1086

grep -n "get \|set \|interface " *.d.ts

Symptoms

This guide profiles the failure behind “TypeScript TS1086 — Accessor Cannot Be Declared in Ambient Context”. It walks through the observable symptoms, a reproducible diagnosis path, the underlying root cause, the concrete fix, and how to verify the change and prevent a regression.

Observed symptoms include:

• error TS1086: An accessor cannot be declared in an ambient context
• A .d.ts or interface uses get/set and fails to compile
• The error appears after moving a class into a declaration file

Reproduce and Diagnose

Reproduce the failure in isolation before changing any code. Work through the checks below in order; each one narrows the search space.

Step 1: Reproduce and locate the accessor

npx tsc --noEmit 2>&1 | grep TS1086

The error line marks the get/set in the interface or declaration file.

Step 2: Convert to a property signature

grep -n "get \|set \|interface " *.d.ts

Replacing accessors with plain property signatures matches what ambient contexts allow.

Likely contributors, in order of frequency:

• An interface or ambient declaration contains a get/set accessor
• A .d.ts file copied from implementation code retains accessor syntax
• declare class with accessor bodies is used where only signatures are allowed

Root Cause

Ambient contexts (interfaces and declaration files) describe types without implementation, so accessors that imply get/set bodies are illegal there. TypeScript reports TS1086 rather than guessing intent.

The Fix

Use property signatures in interfaces and declaration files, expose the value as a readable property, or move the accessor into a real class implementation.

Watch out: Flattening an accessor to a property can change readonly semantics; add readonly where the value must not be set.

// ❌ interface { get name(): string; }  -> TS1086

interface User {
  readonly name: string;   // ✅ property signature
  age: number;
}

// accessors belong in a real class
class UserImpl implements User {
  private _name = '';
  get name() { return this._name; }
}

Verify and Prevent

Run tsc –noEmit and confirm TS1086 is gone; verify consumers still read the property correctly at runtime.

Once verified, add a regression test that reproduces the original symptom so the failure cannot silently return.

This class of failure is usually environmental rather than pure logic, so capture the exact command, the environment variables, and the working directory in your bug report. Reproduce it in the smallest possible script, then widen the scope only once the minimal case is understood. A short written checklist for this failure mode saves hours the next time it appears.