dshmarket 1.73.7 Attaches Release Tarball (Oct 31, 2026)

dshmarket 1.73.7 Attaches the Built Tarball to Its Own Release — Git-Source Installs Stop Needing Build Approval, Issue to npm in Under Three and a Half Hours on the Ninth Release Evening in Ten.

Nine evenings in ten now carry a dshmarket release. dshmarket 1.73.6: Three Fixes, webp Covers (Oct 30, 2026) closed October 30, and 1.73.7 followed at 19:02:29 UTC on October 31 per the npm registry — the ninth release evening in the last ten, every evening from 10-22 through 10-31 except a quiet 10-25. The version carries exactly one change, and it is aimed not at the market’s interface but at its second install path.

The wall: build approval on a moving commit

dsh-market publishes a built artifact to npm on every release, but per PR #1073’s description that artifact previously had no build-free landing point for installs from GitHub source. There, pnpm stops with ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED: the git-hosted package needs to execute build scripts and is not in the allowBuilds allowlist. Issue #1072, filed by @NeuroPaw at 15:40:48 UTC on October 31, documents the escape hatch’s flaw on a DSH Desktop 0.2.1-rc.5 host with an empty profile: writing in the key pnpm prints does unblock the install, but the key is bound to the exact commit — the issue shows the codeload hash inside it — while the profile holds a floating spec, github:dsh-market/dsh-market, that re-resolves on every update. The approval is per-commit, the spec is not, so the wall returns on the next update.

Per the issue’s own tally, the authorization chain had been patched repeatedly — 52 allowBuilds-related issues and 15 or more fix PRs between August 15 and October 29, covering how keys are written and approved, pre-writing the next commit’s key at update time, resolving self-installs to the npm package, and floating-branch cases. The issue’s framing is that none of those removed the need for approval; this change removes the approval itself.

What the PR changes

PR #1073 merged at 18:43:23 UTC — three hours after the issue — and touches three files with 28 added lines and none removed. Per its description, the release workflow now runs npm pack --ignore-scripts --pack-destination dist after npm publish and passes dist/*.tgz to gh release create, so each release page carries the tarball as an asset; both READMEs gain an install-from-GitHub-source entry pointing at that tarball directly. The --ignore-scripts flag is the load-bearing part: npm publish has just built via prepack, so packing the existing artifact — rather than letting a second prepack run — is stated to keep the asset the same content as the same-version npm package and to skip a redundant tsc/tsdown pass. The change rides only the tag path, per the PR: the dev channel’s workflow_dispatch behavior is unchanged, and no dependencies or secrets were added.

The first-release check passed on arrival

The PR’s verification section is explicit that the tag path cannot be rehearsed in the PR’s own CI and names two checks for the first post-merge release: that the release page shows dshmarket-<version>.tgz, and that an empty-profile dsh plugin --profile <p> add <tarball URL> succeeds without pnpm writing an allowBuilds entry. v1.73.7 is that first release, and the first check already reads green: the release page carries dshmarket-1.73.7.tgz — 849,048 bytes, 18 downloads as of this article’s 2026-11-01 fetch, well under the ~5 MB side effect the PR estimated. The profile-side add remains the PR’s stated check rather than one re-run here. The release was out at 19:00:55 UTC and npm at 19:02:29 UTC: three hours and twenty-one minutes from issue to registry.

The wall: build approval on a moving commit

What the PR changes

The first-release check passed on arrival

More in this series