So far the libraries share their code inside the repository: The build compiles everything together. As soon as an application outside needs them (the booking in a repository of its own, a customer, another team), the library needs a version, an interface and a package. This lesson turns a UI library kladde-ui into a package, installs it in a second application, and lets nx release work out the version without publishing anything.

State of the checks. Run (Node 24.22.3, Nx 24.0.6, Angular 22.2, ng-packagr 22.2, Vitest 4.1.12, throwaway projects outside the repository): creation with --publishable, lint, test and build (exit 0, after one correction), npm pack, installation in a second application including build (exit 0) and test (1 of 1), nx release --first-release --dry-run and nx release publish --dry-run (exit 0 each, afterwards no tag, no change). Read: Nx "Manage Releases" (as a summary) and Learn "Publish and download npm packages with Azure Artifacts". Not run: any real publishing, a feed, nx release without --dry-run, Verdaccio. Open: the specifications of Semantic Versioning and Conventional Commits, the Nx page on npm packages (404).

Buildable and publishable

The libraries from 0102 are neither: The application imports their source code through the paths in tsconfig.base.json and builds them along. According to its help, the generator @nx/angular:library knows the switches --buildable and --publishable. The difference as we understand it (the help gives only short descriptions): A buildable library has a task build with ng-packagr and can thus be cached individually; a publishable one additionally has a package with a name and a version for consumers outside.

A package is a promise: Name, public interface and version are, from the moment of publishing, a commitment to strangers. That is why you do not publish every library but the few that someone from outside needs. For the Kladde, that is kladde-ui: building blocks that office and booking share and that a third party may use.