Verify and Release SiteKit Packages

Verify and Release SiteKit Packages

Prerequisites

Use Node.js 22.12 or later (Node.js 24 LTS recommended), npm and Bun 1.4.0 for repository development and release checks. Bun is not required by installed library consumers. Both package manifests are configured for public npm publication and run bun run --cwd ../.. release:check in prepublishOnly. The workspace root remains private. Configuration does not itself publish either package.

The public repository is dataarthub/sitekit; both packages declare its source directory and issue tracker. A release still requires publishing rights for the @alneas scope, manual npm authentication and an approved source revision. The author is dataarthub; the license is MIT. Do not invent repository URLs. The Astro peer floor >=7.3.3 <8 records the lowest version currently exercised by the consumer checks; support for earlier 7.x releases has not been established.

Public import

The core package is @alneas/sitekit; the optional adapter is @alneas/sitekit-cloudflare. Install the core artifact as described in the source verification guide. A minimal consumer check is:

import { defineSite } from '@alneas/sitekit/config';
console.log(defineSite({ id: 'example', content: { snapshot: { siteId: 'example', revision: 1, posts: [], assets: [] } } }).id);

Step-by-Step Implementation

1. Verify dependencies and the exact artifacts

bun install --frozen-lockfile --ignore-scripts --registry=https://registry.npmjs.org
bun run release:registry
bun run release:check

release:registry checks the exact Appkit 0.1.0 versions on npmjs and their tarball integrity against the lockfile. The full gate reruns it, checks public boundaries, generated-document freshness, types, tests, static builds, actual Bun and npm tarball installation and the example site. Both pack paths reject unresolved workspace:, file: and link: dependencies in artifact manifests. They verify declared exports, identical license files and exclusion of tests, source maps and private paths. The two exported CSS source files are intentional package assets.

2. Establish the source revision

Inspect all files to be committed and create the initial public source commit when none exists. Remove Finder metadata and keep archives, local review evidence, private sibling sources and dependency trees outside the commit. Local review tags identify pre-release audits; create the release tag only on the final reviewed release commit after the following release requirements are met.

3. Prepare the release configuration

The initial publication is performed manually by a maintainer with npm authentication and @alneas scope publishing rights. No automated publishing workflow is enabled. Preserve repository.directory as packages/core or packages/cloudflare; leave credentials outside the repository. A future automated release may configure npm Trusted Publishing separately.

Both packages omit private and run the full validation gate before directory publication. The boundary check rejects a missing/replaced validation hook or a private package manifest. Internal pack tests use --ignore-scripts to avoid lifecycle recursion and still verify every packed manifest, declared export and file boundary. The publishable source manifests already use registry-compatible dependency versions; workspace-only specifiers remain at the private root. Do not introduce workspace:, file: or link: dependencies into a release artifact.

4. Publish in dependency order

Publish @alneas/sitekit first. Confirm the exact core version is readable from npmjs, then publish @alneas/sitekit-cloudflare, whose peer depends on core ^0.1.0. A partial release must resume with the remaining package rather than overwriting an existing npm version. From the repository root, after reviewing and pushing the release commit:

npm publish --workspace packages/core --access public
npm view @alneas/sitekit@0.1.0 version --registry=https://registry.npmjs.org
npm publish --workspace packages/cloudflare --access public
npm view @alneas/sitekit-cloudflare@0.1.0 version --registry=https://registry.npmjs.org

Each npm publish runs its package’s full prepublishOnly gate. Complete any npm authentication prompt manually. Run a fresh registry-only consumer install after both publications.

Update the canonical README/guide installation commands to registry package names and date the changelog in the approved release change. Regenerate wrappers and package READMEs with bun run docs:prepare; never edit generated copies directly. Until publication is confirmed, keep installation instructions explicit about candidate artifacts. Verify the final GitHub/npm README after delivery.

Verification

Expect Public Appkit registry verification passed, a passing release:check, matching license bytes and no unresolved local dependency protocols in either packed manifest. Inspection of scripts/check-docs.mjs finds credential-detection regular expressions, not embedded credentials; scripts are excluded by package files allowlists. Each package’s publication hook runs the full validation gate. The root workspace is intentionally unpublishable.

Troubleshooting / Common Pitfalls

• Missing Appkit version or changed integrity: stop and resolve the registry/lockfile mismatch before release.
• workspace: in an artifact manifest: fix the pack pipeline and rerun both Bun and npm consumers; do not publish the raw workspace directory.
• npm authentication or permission failure: complete the maintainer’s manual login and confirm publishing rights for the @alneas scope. Trusted Publishing is not required for this manual initial release.
• Generated-document drift: update canonical inputs, run the normal generator explicitly, then rerun the freshness check.
• A private-path failure: remove the actual path or dependency. Generic compatibility contracts and integration descriptions do not themselves constitute private material.