Package Publication Evidence
Use this page to verify the first public npm publication and the staged publishing workflow for the Hyper-Dank packages.
Library docsLibraries
First public package set
The first public npm package set is 0.1.0. The repository is already prepared for a later 0.1.1 documentation metadata release, so use npm registry metadata as the source of truth when checking what consumers can install right now.
| Package | npm package | Version | Integrity |
|---|---|---|---|
@macavitymadcap/hyper-dank-ui | npm | 0.1.0 | sha512-iPpySpB1FAOSQkqVwku3UGUVAiQtVKuf/MiPew9NfTI1FsyDwJ1sCo0F9XC8nfpJq+Kxzn15v2W7B2tWrVxSBA== |
@macavitymadcap/hyper-dank-data | npm | 0.1.0 | sha512-+WFSoHSsqAzGQXf2BDmCVJZoy4SAFlXVUFqktrO0wknTPJcPwfz1PpB4bEznwU13Ggn7qLO5f9sq8coj0vjP+Q== |
@macavitymadcap/hyper-dank-transport | npm | 0.1.0 | sha512-dzn3bqdfvsAZPYyzToqtWlfKX+3fJiJeIE2kBWYpFB0wSwfPNkix5/xDaSUwC280ADYrNF4OZZME9c//jsYfww== |
@macavitymadcap/hyper-dank-automation | npm | 0.1.0 | sha512-gbEPdbsBesHujE0PWQeteWSv5v7lgqOFMOoqQbV68SMLctSkLtErvx/4G7vKw4QYSj7o6KRH3ejtTNUxVpai1g== |
Approval and provenance status
The first live 0.1.0 packages were published manually after the local npm CLI did not expose the staged publish command. Those tarballs have npm registry integrity and signature metadata, but they do not have GitHub OIDC provenance from the trusted-publishing workflow.
The root hyper-dank release and the public library package releases are separate Release Please manifest entries. The root package keeps its 2.x application history. The public libraries stay on their own shared 0.x line because their npm history started with the first public monorepo package set.
Merging normal work to main does not publish npm packages directly. Release Please first opens or updates a release PR. When that generated release PR is merged and GitHub releases are published, the Publish npm packages workflow runs automatically from the hyper-dank-ui-v* component release event. That single canonical event represents the linked library package set, so the workflow does not race across every component release tag. It verifies metadata, builds and smoke-tests the package tarballs, skips any package version that already exists on npm, then stages only unpublished package versions with npm trusted publishing and --provenance.
The same workflow can still be run manually. Use the default dry_run=true to check the package set without staging anything. Use dry_run=false only for recovery or a deliberate manual release after checking that npm trusted publishers are configured for every package. Treat the npm-publishing environment approval, npm staged package review, and npm provenance badge as the approval evidence for automated package sets.
Integrity checks
Check the live registry metadata before announcing or debugging a package release:
npm view @macavitymadcap/hyper-dank-ui version dist.integrity dist.shasum dist.signatures --json
npm view @macavitymadcap/hyper-dank-data version dist.integrity dist.shasum dist.signatures --json
npm view @macavitymadcap/hyper-dank-transport version dist.integrity dist.shasum dist.signatures --json
npm view @macavitymadcap/hyper-dank-automation version dist.integrity dist.shasum dist.signatures --json
For a consumer smoke, install from the registry in a clean directory and run the package imports from Consumer setup. For a release workflow smoke, run bun run test:packages before staging packages.
Release-note checklist
Release notes that announce package publication should link back to this page and include:
- package names and versions;
- npm package URLs;
- whether the release was manual, staged, or trusted-published with provenance;
- integrity verification command output or a link to the GitHub workflow run;
- external consumer install smoke notes.