TypeScript access boundaries: compile-time private members and runtime-reachable exports

The short answer

If a member must not be reachable by consumers at runtime, TypeScript's private and protected modifiers cannot deliver that guarantee—they are erased during compilation and the emitted JavaScript exposes an ordinary property. Only ECMAScript #private fields provide engine-enforced privacy, provided your emitted output preserves them. For a library whose consumers compile with different targets, use #private for members that must be unreachable, set your published output to ES2015 or higher, and treat private/protected as IDE ergonomics rather than security.

Why the two mechanisms differ

TypeScript's access modifiers exist only in the type system. After tsc runs, private cache becomes this.cache—reachable via bracket notation or reflection. This is by design: TypeScript types are fully erasable.

#private fields are a JavaScript language feature. The engine itself throws a TypeError on external access. However, the guarantee depends on the compilation target: when TypeScript targets below ES2015, it downlevels #private to a WeakMap-based shim. While this blocks casual access, it is generated code rather than native enforcement. The boundary is only as strong as the final artifact the consumer runs.

Recommendation for a multi-target library

1. Publish compiled output at target: "ES2015" or newer (ES2022 is a modern floor) so #private is emitted natively.
2. Use #private for members that must be unreachable; use private/protected for members where compile-time discipline suffices.
3. Ship .d.ts declarations so TypeScript consumers still receive type checking against your public surface.
4. Do not rely on module scope as a privacy boundary; any exported declaration is public.

Combining protected inheritance with runtime privacy

protected and #private compose awkwardly because #private fields are invisible even to subclasses. The standard pattern is to keep storage #private and expose a protected accessor:

class Base {
  #state = 0;
  protected get state() { return this.#state; }
  protected bump() { this.#state++; }
}

The cost is a small amount of indirection and the requirement that subclasses use the accessor rather than direct field access. In exchange, subclasses maintain controlled access while external consumers face a hard runtime boundary.

Settings that keep the boundary predictable

strict mode does not affect privacy enforcement; it only controls type-checking diagnostics. The critical settings are target (ES2015+) and the consumers' downstream bundler settings. Verify the shipped artifact, not just the source:

tsc --target ES2015 --strict demo.ts
node -e "const D = require('./demo.js').default; const d = new D(); console.log(d.secret)"

Accessing a private member this way will succeed; accessing a native #private field will throw. Inspect the emitted file to confirm whether #field syntax survived or was downleveled to a WeakMap.

Assumptions and caveats

This assumes stable TypeScript 5.x and runtimes supporting native private fields (Node 12+). If consumers re-bundle your source to ES5, no language mechanism fully hides a member; you would need renaming or closure-based encapsulation. If the goal is merely to prevent accidental misuse, compile-time private is usually sufficient.