pnpm-upgrade-package

작성자: langfuse

pnpm 워크스페이스 의존성을 대상/최신 버전으로 업그레이드: 직접/전이적 범프, 릴리스 연령 확인, 임시 오버라이드, minimumReleaseAgeExclude,…

npx skills add https://github.com/langfuse/langfuse --skill pnpm-upgrade-package

PNPM Upgrade Package

Use this skill for interactive dependency bumps in Langfuse.

Read Order

  • Use this SKILL.md for the end-to-end workflow.
  • Run the main helper once at the start of the upgrade: node .agents/skills/pnpm-upgrade-package/scripts/check-release-age-window.mjs <package> [targetVersion]

Apply This Skill

  • Ask for the package name if the user did not provide one.
  • Ask for the target version if the user did not provide one.
  • Run the main helper once as the first analysis step and use that single output for scope, exclusion decisions, and the final bump.
  • If the target package is not directly declared anywhere, run pnpm why -r <package> to find which direct dependency brings it in, then inspect whether the current top-level parent already allows the requested transitive version via its dependency range.
  • If the current parent range already covers the requested transitive version, prefer a lockfile refresh / reinstall path over bumping the parent manifest.
  • If the current parent range does not cover the requested transitive version, upgrade that parent dependency instead of adding the target package directly unless the user explicitly wants that.
  • If pnpm will not move an already-allowed transitive version, a scoped overrides entry in pnpm-workspace.yaml may be used as a temporary resolution tool. Before finishing, prove whether the override is still required: remove it, run pnpm install, then run pnpm dedupe. Inspect the diff after each generated change. If the target version remains without the override, do not keep the override; keep or restore it only when pnpm reverts or drifts from the requested version without it.
  • Never manually edit pnpm-lock.yaml; regenerate lockfile changes with pnpm commands only. If a lockfile-only refresh causes unrelated churn, adjust the pnpm command and rerun instead of patching the lockfile by hand.
  • After fixing or upgrading a package, run pnpm dedupe. Always inspect the diff after dedupe and revert that generated attempt if it introduces unrelated churn.
  • Resolve the registry latest version, but do not silently upgrade to latest unless the user asked for latest.
  • Compare the target version with the latest version installable under the current minimumReleaseAge window.
  • Before generating lockfile changes, run pnpm install --dry-run --ignore-scripts to catch resolver and policy failures without writing pnpm-lock.yaml or node_modules.
  • Inspect any dry-run "would make changes" output as baseline resolver drift before deciding which write command is safe.
  • Ask before adding minimumReleaseAgeExclude entries for the target package, exact dependency companions from dependencies or optionalDependencies, or locally installed exact peer dependencies.
  • Finish with pnpm why -r <package> to confirm that only the intended version remains in the workspace.
  • In the final response, include a copy-pasteable human commit command using the resolved package name and target version. Use a branch-safe package slug for scoped packages, but keep the exact package name in the commit message: git switch -C deps/bump-<package-slug>-to-<version> && git commit -m "chore(deps): bump <package> to <version>" --no-verify

Quick Commands

  • Analysis pass: node .agents/skills/pnpm-upgrade-package/scripts/check-release-age-window.mjs <package> <targetVersion>
  • Transitive provenance / final graph verification: pnpm why -r <package>
  • Inspect a current parent manifest on the registry: npm view <parent>@<installedVersion> dependencies peerDependencies optionalDependencies --json
  • Preflight resolver/policy check: pnpm install --dry-run --ignore-scripts
  • Optional lockfile cleanup: pnpm dedupe
  • Bump in the root workspace: pnpm -w up <package>@<version>
  • Bump in one workspace: pnpm --filter web up <package>@<version>
  • Bump everywhere that should move together: pnpm -r up <package>@<version>
  • Verify temporary override removal: remove the override, then run pnpm install and pnpm dedupe
  • Human commit helper: git switch -C deps/bump-<package-slug>-to-<version> && git commit -m "chore(deps): bump <package> to <version>" --no-verify

langfuse의 다른 스킬

clickhouse-best-practices
langfuse
ClickHouse 스키마, 쿼리 또는 구성을 검토할 때 반드시 사용해야 합니다. 권장 사항을 제공하기 전에 반드시 확인해야 하는 28개의 규칙이 포함되어 있습니다. 항상 읽어보세요…
official
skill-creator
langfuse
효과적인 스킬을 만들기 위한 가이드입니다. 사용자가 Claude의 기능을 확장하는 새 스킬을 만들거나 기존 스킬을 업데이트하려 할 때 이 스킬을 사용해야 합니다.
official
vercel-react-best-practices
langfuse
Vercel Engineering의 React 및 Next.js 성능 최적화 가이드라인입니다. 이 스킬은 React/Next.js를 작성, 검토 또는 리팩토링할 때 사용해야 합니다…
official
add-model-price
langfuse
Use when editing worker/src/constants/default-model-prices.json, packages/shared/src/server/llm/types.ts, pricing tiers, tokenizer IDs, or matchPattern regexes…
official
analyze-cloud-costs
langfuse
Metabase cost marts를 사용하여 Langfuse Cloud 인프라 비용 구조를 분석합니다. 클라우드 지출, AWS 대 ClickHouse 비용 분할, 비용…에 대해 질문받을 때 사용합니다.
official
backend-dev-guidelines
langfuse
Build or review Langfuse backend code. Use for tRPC routers, public REST APIs, BullMQ processors, services, middleware, Prisma or ClickHouse access,…
official
clickhouse-best-practices
langfuse
ClickHouse 스키마, 쿼리 또는 구성을 검토할 때 반드시 사용해야 합니다. 권장사항을 제공하기 전에 확인해야 하는 28가지 규칙이 포함되어 있습니다. 항상 읽으세요…
official
code-review
langfuse
Review Langfuse code changes for correctness, regressions, and best practices.
official