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.