chore(pnpm): pin the version where contributors read it, and reject npm - #5
Merged
Conversation
…tor never reads it Part of a cross-repo pass making every JS repo pnpm-only the same way. This repo already used pnpm everywhere — scripts, CI, build-vsix.sh — but nothing said so to a package manager. `npm install` here would have succeeded, written a `package-lock.json` nobody tracks, and produced a second dependency set. And the version lived in `.github/workflows/ci.yml` as `pnpm/action-setup@v6 with: version: 10.4.1`, which a contributor installing locally never sees. Concretely why the pin matters: this machine has a stale pnpm 8.14.0 ahead of pnpm 10 on PATH. In a sibling repo with no `packageManager` field, a plain `pnpm install` silently REWROTE a lockfileVersion 9.0 lockfile with pnpm 8. The pin is what makes corepack fetch the right one instead. - `packageManager: pnpm@10.4.1` — same version CI already used, so nothing about the build changes. The `version:` input is removed from ci.yml, because action-setup errors when both are set; package.json is now the one source. - `preinstall: node scripts/only-pnpm.mjs` rejects npm/yarn/bun. Local on purpose: `npx --yes only-allow pnpm` (the usual recipe) downloads and runs an unpinned registry package with installer privileges on every install. - `package-lock.json` / `yarn.lock` gitignored. The .vsix is unaffected. `.vscodeignore` already excludes `scripts/**`, and `vsce package --no-dependencies` never installs, so no lifecycle script from this repo can reach a candidate's editor. Verified under corepack pnpm@10.4.1: `install --frozen-lockfile` clean, `tsc -p ./ --noEmit` clean, `vitest run` 107/107 passing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Greptile SummaryThe PR centralizes the pnpm 10.4.1 pin in
Confidence Score: 4/5The PR appears safe to merge, with only a non-blocking correction needed for the guard’s invalid documentation pointer. The package-manager pin and CI setup are internally consistent, while the only accepted issue is that rejected installs receive recovery guidance pointing to nonexistent README content. Files Needing Attention: scripts/only-pnpm.mjs
|
| Filename | Overview |
|---|---|
| package.json | Adds the pnpm 10.4.1 package-manager declaration and wires in the preinstall guard. |
| scripts/only-pnpm.mjs | Correctly rejects non-pnpm user agents, but its failure message points to contributor documentation that does not exist. |
| .github/workflows/ci.yml | Removes the duplicate action input so CI obtains the pnpm version from the root package manifest. |
| .gitignore | Ignores alternate lockfiles and repository-local Claude session state. |
Reviews (1): Last reviewed commit: "chore(pnpm): the pnpm version was pinned..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| ` corepack enable # once, pins the version from package.json\n` + | ||
| ` pnpm install\n\n` + | ||
| `npm/yarn would write a second, unshared node_modules and a lockfile this\n` + | ||
| `repo does not track. See CONTRIBUTING notes in README.md.\n\n`, |
There was a problem hiding this comment.
The rejection message directs contributors to “CONTRIBUTING notes in README.md,” but those notes do not exist, leaving users who encounter the new guard with an invalid documentation pointer.
Suggested change
| `repo does not track. See CONTRIBUTING notes in README.md.\n\n`, | |
| `repo does not track.\n\n`, |
Merged
pa-arth
added a commit
that referenced
this pull request
Aug 26, 2026
#4 and #5 have sat on main unreleased since 2026-08-23. #4 said so in its own commit message — "No version bump: this changes packaging only and rides the next release" — and there has not been one since. That matters more than a packaging tidy usually would, because of how this extension reaches anyone. There is no marketplace auto-update: `promptster start` sideloads the embedded .vsix with --force on every run, so the version a candidate gets is the version welded into the CLI they installed. An unreleased fix here is not late, it is absent. This machine is the evidence — Cursor holds promptster.promptster-0.3.1, and promptster-cli embeds promptster-0.3.1.vsix with SourceTag v0.3.1. Patch, not minor, and checked rather than assumed: `git diff v0.3.1..main` touches .github/, .gitignore, .vscodeignore, package.json and a new scripts/only-pnpm.mjs — no src/ at all. The compiled dist/ payload is identical to 0.3.1's, so nothing about what the extension collects or emits changes. Gates: pnpm install --frozen-lockfile, tsc -p ./, and vitest 107/107 across 7 files — including the 19-case published-exclusion-list gate #4 added, which is what will fail if the .vsix ever starts carrying repository machinery again. NOT run: `pnpm run lint`. eslint is not a devDependency and CI does not invoke it, so the script references a tool this repo does not install. Left alone here rather than fixed inside a release commit. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One of five repos in a cross-repo pnpm pass (cc-audit#34, promptster-hire#21, plus Promptster / promptster-teams / promptster-backend).
Why
This repo already used pnpm everywhere — scripts, CI,
build-vsix.sh. Nothing said so to a package manager:npm installwould have succeeded and written an untrackedpackage-lock.json, i.e. a second, untested dependency set. And the version was pinned inci.yml(version: 10.4.1), which is precisely where a contributor installing locally never looks.Not hypothetical. This machine has a stale pnpm 8.14.0 ahead of pnpm 10 on
PATH; in a sibling repo with nopackageManagerfield, a plainpnpm installsilently rewrote a lockfileVersion 9.0 lockfile with pnpm 8. The pin is what makes corepack fetch the right one.What changed
packageManager: pnpm@10.4.1— the same version CI already used, so the build is unchanged.version:removed fromci.yml, sincepnpm/action-setuperrors when both are set.preinstall: node scripts/only-pnpm.mjsrejects npm/yarn/bun. Local rather thannpx --yes only-allow pnpm, which runs an unpinned registry package with installer privileges on every install.package-lock.json/yarn.lockgitignored.The .vsix is unaffected
.vscodeignorealready excludesscripts/**, andvsce package --no-dependenciesnever installs — no lifecycle script from this repo can reach a candidate's editor.Verification (corepack pnpm@10.4.1)
pnpm install --frozen-lockfilepnpm exec tsc -p ./ --noEmitpnpm exec vitest run🤖 Generated with Claude Code