fix: pin pnpm to 11.18.0 so pnpm trusted publishing works

[nimrodkor]

No description provided.

[baz-reviewer]

Generated description

Pin pnpm to 11.18.0 in packageManager and remove the workflow-specific version override from the release and PR test jobs so npm trusted publishing uses the expected installer version. Allow esbuild in the workspace config so dependency installs keep working under the new pnpm setup.

Topics

Topic	Details
Workspace builds	Allow esbuild to build during workspace installs to keep dependency installation working with the new pnpm setup. Modified files (1) pnpm-workspace.yaml Latest Contributors(1) User Commit Date nimrod@baz.co fix: allow esbuild bui... July 29, 2026
Trusted publishing	Pin pnpm for the release and PR test flows so GitHub Actions and npm trusted publishing use the same version. Modified files (3) .github/workflows/pr-tests.yaml .github/workflows/release.yml package.json Latest Contributors(2) User Commit Date nimrod@baz.co fix: pin pnpm to 11.18... July 29, 2026 internal-baz-ci-app[bot] chore(main): release 0... July 29, 2026

---

_{Review this PR on Baz | Customize your next review}

[baz-reviewer]

⚠️ Advanced Security cannot run on this PR.

Your organization's Advanced Security usage limit has been reached. To continue using Advanced Security reviews, please upgrade your plan or increase your usage limits in your account settings.

[baz-reviewer-dev]

pnpm/action-setup@v4 omits with.version, so it falls back to the packageManager field in the PR's package.json — an unreviewed PR can inject an arbitrary pnpm version/binary into CI before pnpm install runs. Should we pin the version explicitly with with: { version: '11.18.0' } so installation doesn't depend on PR-controlled content?

Want Baz to fix this for you? Activate Fixer

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
.github/workflows/pr-tests.yaml around lines 34-37 in the "install pnpm" step using
pnpm/action-setup@v4, the workflow currently omits the required with.version, so pnpm
version selection is influenced by the PR-controlled package.json "packageManager"
field, letting an attacker inject an arbitrary pnpm version/binary into CI before pnpm
install runs. Fix by reintroducing an explicit pinned pnpm version in that step (e.g.,
with: { version: '11.18.0' }, matching the version currently used by the project) so CI
always installs the expected pnpm binary regardless of PR content. If pnpm/action-setup
supports an option to ignore/override the package.json packageManager field, enable it
as well to prevent future bypasses.