Test from a real consumer

Start from the behavior you can observe. A fixture application installs the tarball and imports every documented entry point using the supported runtime.

Tests inside the package can pass while exports, filenames, declarations, or runtime dependencies fail after installation. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to test consumers through relative paths into the package source. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to pack the package, install that artifact in an isolated consumer, and run public API examples there. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Develop the package against a real consumer and make build and test behavior reproducible from a clean checkout. Record enough evidence that another developer can repeat the result without relying on your memory.

Create CommonJS or ESM consumers as appropriate and verify runtime imports, types, errors, and documented examples. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.