intermediate

Public versus private API

Expose narrow stable contracts and keep internal helpers private so refactors do not become breaking changes.

A module's public API is the set of exports other teams may depend on; everything else is implementation detail. Narrow public surfaces reduce breaking-change risk and make refactors cheaper. In TypeScript and package ecosystems, barrel files and export maps are policy tools, not just convenience.

On interviews: describe how you prevent consumers from importing internal helpers. Mention semver, deprecation windows, and when to break versus extend contracts.

Common pitfalls: exporting everything from index files; leaking internal types in public signatures; refactoring helpers that were already imported widely.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

  • Define explicit public entry points per package or folder.
  • Keep internal symbols unexported or marked private.
  • Review new exports in code review.
  • Document stability expectations for public contracts.