Local package development

Publish types and build output

Compile only when necessary and align JavaScript entry points, source maps, declarations, and package exports.

9 minute lesson

~~~

The TypeScript version emits JavaScript and declarations into matching export targets, then verifies both from the consumer fixture. This is a small part of a small slugify-title package that is tested locally, consumed from another project, and published safely, but the boundary it creates affects everything that follows.

A build exists to produce a supported consumer artifact, not because every package needs a dist directory. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to point exports at source files that the supported runtime cannot execute. It makes later failures harder to locate. Instead, map every export to an existing built file and declaration, clean stale output, and test the packed artifact. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Develop the package against a real consumer and make build and test behavior reproducible from a clean checkout. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Break one declaration path intentionally, observe the consumer failure, and add a release check that catches it. Hand the result to someone else and see whether the behavior is clear without an oral explanation.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →