Publishing a component to a private NPM registry

WHAT THIS TESTS This verifies you understand the full path from a source component to an installable, correctly described package on a private registry.

A GOOD ANSWER COVERS Start with package.json. Use a scoped name like at-yourorg-button, set version following semver, and point the registry for that scope in .npmrc. Declare entry points: main for CommonJS, module for ESM, types for the declaration file, and ideally the modern exports map. Add a files array or npmignore so only dist and required assets ship, not tests or source configs. List react and react-dom as peerDependencies so consumers dedupe a single copy. Build with your bundler to emit ESM, CJS, and type declarations into dist. Run npm pack and inspect the tarball to confirm contents before shipping. Authenticate to the private registry with a token, then run npm publish, passing access restricted for a private scope. Tag versions in git and ideally automate the whole flow in CI on a release.

COMMON WRONG ANSWERS Running npm publish on raw TypeScript or JSX with no build, so consumers cannot import it. Omitting the types field, losing IntelliSense. Bundling react into the package, causing duplicate-React hook errors. Forgetting registry auth so publish hits the public registry or fails.

LIKELY FOLLOW-UPS How do you automate publishing in CI. How do you handle prerelease or canary tags. How do you keep the published tarball minimal.

ONE CONCRETE EXAMPLE You set name at-acme-button, mark react as a peer dependency, build dist with ESM, CJS, and d.ts files, confirm via npm pack that only dist ships, authenticate with a CI token, and run npm publish access restricted, after which teams install at-acme-button from the private registry with working types.