cloudflare / cloudflare/workers-sdk
CI: report package raw/gzip size deltas against the PR merge base
- Dominant language
- TypeScript
- Stars
- 4.5k
- Forks
- 1.5k
- Avg merge
- 3d 8h
- Merged PRs (30d)
- 186
Description
## Problem
Changes to bundled dependencies, source maps, generated files, and packaging configuration can materially change the published sizes of Wrangler, Miniflare, and `@cloudflare/vite-plugin`, but pull requests currently provide no package-size signal.
The comparison also needs to use the same base that CI actually tested. Pull-request CI checks GitHub's synthetic merge commit. Comparing that result with a newly fetched or moving `main` can produce a misleading delta if `main` has advanced since the merge ref was created.
## Proposed solution
Add a package-size workflow and a small repository-owned reporting script.
For each pull-request run:
1. Check out GitHub's synthetic PR merge commit with enough history to inspect its parents.
2. Record:
- candidate: `git rev-parse HEAD`
- exact baseline: `git rev-parse HEAD^1`
3. Verify that the candidate is a two-parent merge commit. The first parent is the exact `main` revision that GitHub used to construct the merge result; do not fetch the latest `main` as the baseline.
4. Install and production-build both revisions under equivalent CI conditions.
5. Initially measure:
- `wrangler`
- `miniflare`
- `@cloudflare/vite-plugin`
6. Determine each package's file set from what would actually be published (for example, the `pnpm pack` manifest/extracted tarball), rather than measuring the whole package directory or `node_modules`.
7. Produce deterministic byte counts for:
- **raw**: sum of regular-file content bytes in the packed package
- **gzip**: sum of a repository-defined gzip calculation over those same files (fixed compression level, preferably level 9)
- optionally also include the actual packed `.tgz` byte size as a separate column
8. Compare candidate against baseline and post/update a single sticky PR comment. Also write the report to the job summary and upload the machine-readable JSON as an artifact.
A report could look like:
| Package | Base raw | Merge raw | Delta | Base gzip | Merge gzip | Delta |
| --- | ---: | ---: | ---: | ---: | ---: | ---: |
| wrangler | … | … | … | … | … | … |
| miniflare | … | … | … | … | … | … |
| @cloudflare/vite-plugin | … | … | … | … | … | … |
The comment should include the candidate and baseline SHAs and ideally a collapsed section showing the largest per-file changes. That is important for distinguishing bundle growth from source-map or generated-file growth.
## Workflow/security details
- Start as an informational signal, not a required size gate. Regressions should be visible without failing otherwise valid PRs.
- Update one sticky comment rather than creating a new comment on every synchronization.
- Skip markdown-only changes.
- Keep the target package list in a small declarative configuration so more publishable packages can be added later.
- Support fork PRs safely. The workflow that checks out and builds PR code should have read-only permissions and upload a strict JSON artifact. A separate privileged reporter (for example, a `workflow_run` job) can validate that artifact and update the PR comment. Do not execute PR-controlled code under `pull_request_target`.
- Pin third-party actions consistently with the rest of this repository.
Workers SDK already uses a sticky-comment action in `.github/workflows/deploy-previews.yml`, so the comment/update mechanism has an established repository precedent.
## Acceptance criteria
- Re-running a PR updates one package-size comment.
- The baseline SHA is the first parent of the exact synthetic merge commit being measured.
- Raw and gzip measurements cover only files that would be published.
- Identical package contents produce identical measurements regardless of checkout directory.
- The comment clearly shows absolute values and signed byte/percentage deltas.
- Results remain available in the job summary and a JSON artifact even when a comment cannot be posted.
- Fork PR code never receives a token capable of writing to the repository.
Contributor guide
Research direction
Read .github/workflows/deploy-previews.yml for the repository's sticky-comment precedent, then inspect the existing CI build and package publication flow for Wrangler, Miniflare, and @cloudflare/vite-plugin. Run the production build and pnpm pack flow for both merge parents; done means deterministic published-file raw and gzip measurements, a signed report in the comment, job summary, and JSON artifact, with fork-safe permissions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, github-actions, typescript
- Domain
- build-system, ci-cd, release, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100