Design package exports

Consumers import slugify-title or slugify-title/strict; they do not reach into dist/internal.js. That contrast gives us something useful to test instead of a rule to memorize.

The exports field defines public import paths and can provide different targets for import, require, types, or environments. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can publish every generated file as an accidental public API and still get one successful demo. Push past the demo. define the smallest export map you can support and test each documented import from a separate consumer, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Turn a useful function into a small package whose public surface and published files are intentional. Save the before-and-after evidence now; it will make the final project review much more honest.

Add one main export and one intentional subpath, then prove an internal path is unavailable. Save the evidence, then explain which requirement would force you to choose a different design.