Skip to content

pstack: pin poteto-mode script devDependencies (bun-types and typescript use latest) #990

Open

Description

@kotarotaniguchi0523

Summary

pstack/skills/poteto-mode/scripts/package.json pins commander exactly, but its dev dependencies use the latest tag:

"devDependencies": {
  "bun-types": "latest",
  "typescript": "latest"
}

Why it matters

  • Installs are not reproducible: bun install can pick a different bun-types or TypeScript on every run.
  • A newly published (or compromised) release is picked up automatically.
  • The typecheck and bun test results then depend on whichever versions happen to be current.
  • Static skill scanners flag this as an unpinned-dependency finding (SkillSpector SC1).

Proposal

  • Pin exact versions for bun-types and typescript, and let Renovate/Dependabot (or a scheduled workflow) update the pins; or
  • Commit a lockfile for scripts/ so the resolved versions are reproducible.

Context

Found by a downstream APM/SkillSpector audit. commander is already pinned exactly; only the two dev dependencies are unpinned.

Related: #531 (CI/validator coverage, including npm dependencies without a lockfile).

Activity

  1. deanrie commented on Oct 27, 2026

    @deanrie

    Hey @kotarotaniguchi0523, one data point for the second option: pstack/skills/poteto-mode/scripts/bun.lock is already committed and resolves bun-types to 1.3.14 and typescript to 7.0.2. A plain bun install in a fresh checkout keeps those versions and leaves the lockfile unchanged, even though bun-types@latest on the registry is 1.4.4 right now (checked with bun 1.4.3). The latest spec only takes effect when the lockfile is regenerated, so day-to-day installs and bun test are reproducible today; the scanner is reading package.json alone.

    What is missing is a check that the lockfile stays in sync. #618 adds a script-packages.yml job that runs bun install --frozen-lockfile plus typecheck and test for this directory and for orchestrate/skills/orchestrate/scripts on every PR touching them, which fails the moment someone bumps package.json without the lockfile. Pinning the two specs in package.json on top of that is a two-line change and makes the scanner happy; that is @poteto's call for the pstack tree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions