Publishing packages

What to publish

Publish compiled JavaScript plus declaration files, never raw sources alone. Consumers run the output directly and type check against the bundled types.

Keep the package lean: compiled files, types, README, and license. Tests and drafts stay in the repository where they belong.

tsc --declaration

compiled output and types are ready

Types field

The types field points the checker at the entry declaration file. Editors and builds follow it automatically, so users get completions with zero setup.

Pair it with the main entry for JavaScript. The two fields together describe one package in two languages: runtime and types.

{ "name": "greetlib", "version": "1.0.0", "main": "index.js", "types": "index.d.ts" }

Semver sketch

Versions signal risk with three numbers: major for breaking changes, minor for new features, and patch for safe fixes. Users read the bump and decide how carefully to upgrade.

Keep the public API small so most releases stay minor or patch. Every exported function is a promise you must keep in the next major line.

export function greet(name: string): string { return "Hello, " + name; }

README first

Write the README before release and start with a runnable example. Installation fades from memory, but a copy paste snippet proves the package works in seconds.

Document one happy path well instead of every option briefly. Users adopt packages with clear first five minutes, not with long option lists.

import { greet } from "greetlib"; console.log(greet("Ada"));

Next: Run with Node

Article author: Arthur Isaev