The Release Candidate: Cutting v1.0.0 In short: A private registry, a scoped , and a pipeline that publishes only when every gate is green. Get the baseline right before you try to break it. Everything is built. Now we ship it, so that there is something real to break. A private registry Proprietary UI libraries do not go to the public npm registry. In production you would use Artifactory, AWS CodeArtifact, or GitHub Packages. To run this locally, Verdaccio is a lightweight stand-in: Scope the registry Without configuration, targets the public registry — which would either fail or, worse, succeed and publish your company's code to the internet. Two things this buys you. Correct routing. resolves privately; still comes from the public registry. Protection from dependency confusion. This is a real supply-chain attack: someone publishes a package on the public registry using your internal name, and a misconfigured install silently prefers it. Scoping the registry to means an internal package is never looked up publicly. Note rather than a literal token. npm expands environment variables in , so the file is safe to commit. Check the package before publishing Chapter 4's rules are easy to state and easy to break. Verify: Four things to confirm in the output: has for and — not . A second copy of Angular means a second DI registry. is present, so consumers can tree-shake. points at , and the schematics are in the tarball. Chapter 9's silent failure. The map lists your entry points, generated by . The release pipeline The publish job runs only after every gate. This is the Chapter 8 ship-or-hold rule, wired up: is the whole ship-or-hold rule expressed in YAML. One red gate and never runs. For this first release, sees the initial feature commits and the API diff reports no prior surface to compare against, so it calculates . Capture the baselines The release is only half the baseline. The other half is the visual baselines , and Chapter 8 was firm about where they come from: generated only in the pinned container, never on a developer's machine. The branch run does this: Every subsequent pull request compares against images produced in this exact container, with these exact fonts. That consistency is what makes the next lesson work. Install it in a consumer The dispatch dashboard is a separate repository. It needs its own — the routing line only, no publish token: And the dispatch grid uses the data table: Note the consumer passes presentation models from a facade — Chapter 7's structure, holding. The application compiles. The grid renders. The dispatch actions sit at the right-hand end of each row, where operators expect them. The consumer's own end-to-end suite is green. The state of the world --- --- Library , published privately Visual baselines Captured in the pinned container, committed Accessibility baseline Zero violations — new library, no debt API snapshot Committed; the contract of record Consumer Dispatch dashboard installed and working Gates All green That is the fortress. Now we attack it. "But I thought a private registry was overkill for an internal library" Plenty of teams share libraries through a path mapping in a monorepo, or by committing a built artefact, and it works. So the extra infrastructure can look like ceremony. Two things it buys that a path mapping cannot. Version pinning per consumer. With a path mapping, every application in the workspace uses whatever is on right now. There is no such thing as the dispatch dashboard staying on v10 during a compliance freeze — Chapter 9's entire LTS story is impossible. A registry is what makes "this app is on 1.0.0 and that one is on 1.2.0" a coherent statement. A real installation experience. Publishing forces you to actually exercise the package: the map, the peer dependencies, the wiring, the tree-shaking hints. A path mapping resolves straight to your TypeScript source and skips all of it, so the first person to find out your entry is missing is a consumer, in production, on upgrade day. Path mapping Published package --- --- --- Consumers can pin a version No Yes LTS branches are possible No Yes map exercised No Yes Peer dependency mistakes surface At runtime, later At install migrations work No Yes Works for teams outside the repo No Yes Setup cost 0 An afternoon The honest exception is a genuine single-repository setup with no plan for a second consumer — Chapter 2's Rule of Three again. The moment a second team or a second release cadence appears, the path mapping stops modelling reality. Recap Scope the registry with so internal packages never resolve publicly. This also prevents dependency confusion. Use for tokens so is safe to commit. Verify the tarball before publishing: peer dependencies, , , and the map. is the ship-or-hold rule in one line. Baselines come from the pinned container , committed by CI, never from a laptop. Get the baseline right before trying to break it. A gate is only as good as what it compares against. Next: the pu…