ci: update dependencies with pnpm/update instead of Dependabot

[zkochan]

Replaces Dependabot for dependency updates. Closes #5 once merged.

Why

Dependabot cannot open a passing pull request against this repository. dist/index.js is committed, and pr-check rebuilds it and fails on any difference — but a bump only touches package.json and pnpm-lock.yaml, so the committed bundle is always the one built by the previous dependency set.

That is exactly why #5 is red. esbuild 0.28 changed the CommonJS init helpers it emits:

// 0.27.7
var h=(t,e)=>()=>(e||t((e={exports:{}}).exports,e),e.exports),

// 0.28.1
var h=(t,e)=>()=>{try{return e||t((e={exports:{}}).exports,e),e.exports}catch(r){throw e=0,r}},

A real change, so a real diff, so git diff --exit-code dist/index.js fails. And it is not specific to esbuild: all twelve runtime dependencies are inlined into that bundle, so any bump can move it.

What this does

pnpm/update has a post-update hook that runs before it commits, so pnpm run build regenerates the bundle in the same commit as the bump — the step Dependabot had no way to run.

- uses: pnpm/update@v0
  with:
    post-update: pnpm run build
    verify: |
      pnpm exec tsc --noEmit
      pnpm test
    changesets: false

verify typechecks and runs the unit tests before the commit is made; the resulting pull request then gets the full matrix from test.yaml.

Runs weekly on Mondays and on demand via workflow_dispatch, guarded with if: github.repository == 'pnpm/setup' so it never runs on a fork.

Notes

• The setup step uses ./ rather than a released tag, so the update runs on the pnpm this action ships. install: false, because pnpm/update deletes the lockfile and node_modules before resolving anything.
• changesets: false — no .changeset directory here.
• github-actions is left at its default (false), so pinned action versions in the workflows are not touched. Worth turning on separately if you want that too; it matches what Dependabot was not doing either.
• There is no .github/dependabot.yml in the repository, so build(deps-dev): bump esbuild from 0.27.7 to 0.28.1 #5 came from a repository-level Dependabot setting rather than a config file. Turning it off is a change in the repository settings, not something this PR can do.

[coderabbitai]

Warning

Review limit reached

Next included review available in 41 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 667a06e1-bc4a-424c-b8ff-8eb93ec30c85

📥 Commits

Reviewing files that changed from the base of the PR and between 0080eca and 511ce33.

📒 Files selected for processing (1)

• .github/workflows/update-dependencies.yaml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Automate dependency updates with pnpm/update

⚙️ Configuration changes ✨ Enhancement 🕐 10-20 Minutes

AI Description

• Adds weekly and manual dependency update automation using pnpm/update.
• Rebuilds the bundle and verifies types and tests before opening update pull requests.
• Restricts write-enabled updates to the upstream repository and serializes workflow runs.

Diagram

sequenceDiagram
  actor Trigger as Schedule or maintainer
  participant Workflow as Update workflow
  participant Setup as Local setup action
  participant Update as pnpm/update
  participant Checks as Build and verify
  participant PR as Update pull request
  participant CI as PR workflows
  Trigger->>Workflow: Start update run
  Workflow->>Setup: Install pnpm 12
  Setup-->>Workflow: pnpm available
  Workflow->>Update: Resolve dependencies
  Update->>Checks: Rebuild, typecheck, test
  Checks-->>Update: Verification passes
  Update->>PR: Commit changes and open PR
  PR->>CI: Run full validation matrix

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use Renovate with post-upgrade tasks

• ➕ Mature dependency policies and grouping controls
• ➕ Can regenerate committed artifacts after upgrades
• ➖ Requires additional bot configuration and repository integration
• ➖ Post-upgrade command execution may require self-hosting or elevated trust

2. Maintain a custom GitHub Actions updater

• ➕ Complete control over update, build, commit, and pull-request behavior
• ➕ Avoids relying on pnpm/update action semantics
• ➖ More scripting, token handling, and long-term maintenance
• ➖ Duplicates dependency resolution and pull-request orchestration already provided by pnpm/update

Recommendation: Use pnpm/update as proposed because its post-update and verify hooks directly solve the committed-bundle mismatch while pnpm remains responsible for its own lockfile. Renovate is viable for broader policy needs, but the added integration complexity is unnecessary for this focused requirement.

Files changed (1) +47 / -0

Other (1) +47 / -0

update-dependencies.yamlAdd verified weekly dependency update workflow +47/-0

Add verified weekly dependency update workflow

• Adds scheduled and manual dependency updates using pnpm/update, with the repository’s local setup action providing pnpm. The workflow rebuilds the committed bundle, typechecks, and runs unit tests before creating a pull request, while upstream-only execution and concurrency controls protect write operations.

.github/workflows/update-dependencies.yaml

[greptile-apps]

Confidence Score: 4/5

The workflow appears safe to merge functionally, with non-blocking cleanup needed for narrative comments and immutable pinning of the write-enabled updater action.

The configured build and verification commands match repository scripts and the committed-distribution freshness gate, while the remaining accepted concerns are maintainability and supply-chain hardening issues rather than established current failures.

Files Needing Attention: .github/workflows/update-dependencies.yaml

Security Review

The write-enabled job references pnpm/update through a mutable major-version tag, allowing a retargeted or compromised tag to execute with repository and pull-request write access.

_{Reviews (1): Last reviewed commit: "ci: update dependencies with pnpm/update..." | Re-trigger Greptile}

[greptile-apps]

Comments narrate workflow configuration

These comments restate the adjacent repository guard, installation setting, build hook, and Changesets input. This duplicates the configuration in prose that must be maintained alongside it and can drift when the workflow changes; remove the narration and use focused tests where the behavior needs coverage.

Context Used: Comments and docs in code are suspicious. Is test ... (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Mutable updater receives write access

The scheduled job invokes pnpm/update@v0 with repository-content and pull-request write permissions. Retargeting or compromising this mutable tag would let code outside the reviewed revision push unauthorized changes or alter pull requests, so pin the action to an immutable commit. How this was verified: The workflow grants write permissions at workflow scope and invokes the updater through the mutable v0 tag without another control restricting its token access.