cloudflare / cloudflare/workers-sdk

CI: report package raw/gzip size deltas against the PR merge base

Open
#15,455 4 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.