Repository navigation
release: publish npm alpha and verify clean-HOME install/uninstall #7
Description
Activity
Altairpaca commented
on Sep 3, 2026 OwnerAuthorMore actionsPre-release packaging audit (2026-09): the clean pack-install CI already exercises all six publishable artifacts (
dshelm,@dshelm/core,@dshelm/dsh,@dshelm/auth,@dshelm/model-knowledge,@dshelm/compat-omo), but the package manifests are not yet consistently ready for a public npm surface.Before publishing the alpha, add a small release-hygiene pass:
- normalize package metadata (
description,license,repository,homepage,bugs,engines,publishConfig.access=public) across every publishable package; - ensure each npm package has a useful package-level README instead of an empty/minimal npm landing page;
- add a repository
CHANGELOG.mdand a maintainer release checklist documenting version/tag/prerelease order and the exact clean-HOME evidence required here; - keep publish automation separate until the manual alpha path is proven once end-to-end.
This deliberately defers Changesets/automatic publishing until after the first real registry release, so release tooling does not hide package-boundary problems.
- normalize package metadata (
Altairpaca commented
on Sep 3, 2026 OwnerAuthorMore actionsRelease-maintenance audit (2026-09-03): two version-coherence risks were found before the first public npm alpha.
- Fixed in PR fix: keep init bundle version aligned with installed CLI #18 / main:
dshelm inithad hard-coded@dshelm/dsh@0.3.0-alpha.0; it now derives the adapter bundle version from the installed CLI package version. - Still a release gate: several published manifests declare verified DSH prerelease dependencies as
^0.1.0-rc.7, whilecompatibility.jsonand the current lockfile only verify0.1.0-rc.7. A registry consumer is not protected by the repository lockfile and may resolve a later, unverified prerelease-compatible version. Before publishing release: publish npm alpha and verify clean-HOME install/uninstall #7, regenerate the lockfile together with exact DSH prerelease pins (or deliberately broaden compatibility only after evidence). Do not make a manifest-only change, becausepnpm install --frozen-lockfilemust continue to prove manifest/lockfile coherence.
PR #17 also removes release-version literals from pack/install CI and makes the QA journey read the DSH package baseline from
compatibility.json.tested.dshPackages.- Fixed in PR fix: keep init bundle version aligned with installed CLI #18 / main:
Altairpaca commented
on Sep 3, 2026 OwnerAuthorMore actions2026-09-03 DSH 0.1.2 source-target update
The latest upstream source release is now
dsh-v0.1.2-rc.1. PR #21 prepares forward-compatible source bridges, but does not promote the verified install baseline.New release blocker discovered during the full package audit:
- the 0.1.2 source tree no longer contains the old
packages/client/runtime/@deepseek-ai/dsh-client-runtimepackage currently used by@dshelm/dsh; @deepseek-ai/dsh-client-modules@0.1.2-rc.1now ownsdsh.clientscanning, boot graph composition,/pluginsbundle delivery and lazy module materialization;- DSHelm browser source in feat: bridge DSH 0.1.2 APIs and redesign the project landing page #21 is decoupled from the removed runtime type package, but
packages/dsh/package.jsonintentionally remains on the verified legacy dependency/inject graph until the candidate manifests andpnpm-lock.yamlcan move together.
Exact promotion work is tracked in #20. The first npm alpha should not publish until #20 has resolved the 0.1.2 client graph (or selected another explicitly verified DSH baseline), regenerated the lockfile, and passed packed install + isolated profile boot + real Web client materialization.
This adds to the previously recorded prerelease-range blocker: do not publish a mixed or caret-resolved DSH prerelease graph.
- the 0.1.2 source tree no longer contains the old
Altairpaca commented
on Sep 5, 2026 OwnerAuthorMore actionsUpdate after PR #28 merge:
Repository-side npm alpha bootstrap preparation is complete on main (
680db824a0720c489641535718673ef59f514f4b). Verified:- guarded npm release workflow merged;
- six-package release order validated;
- deterministic package closure passed;
- npm 11.19.1
npm publish --dry-run --access public --tag alphasucceeded for all0.3.0-alpha.0packages; - release evidence artifact:
9938939100(sha256376d1c1e3a9b4881ed0108ad199bfe5c36ad9de6027e87272f3c24666ea238bf).
Remaining blocker is maintainer-side first publication bootstrap only: npm ownership/scope access, 2FA-enabled credential path, then immediate migration to Trusted Publishing/OIDC. After the first real publish, run public-registry clean-HOME smoke before closing this issue.
Goal
Turn the current source-preview distribution into a verifiable public alpha that a user can install without knowing the repository layout.
Acceptance criteria
dshelm,@dshelm/dsh, and any internal packages that must be externally resolvable);npx dshelm init --yessucceeds from a clean HOME with a supported DSH installation;dshelm doctorreports the installed profile/bundle and gives an actionable next command;Evidence to attach
doctoroutput before and after install;This is the P0 distribution gate from
docs/community-roadmap.zh-CN.md; passing unit tests alone is not sufficient evidence for this issue.