deps(worker): bump wrangler 4.115.0 + vitest-pool-workers 0.19.0 - #51
Merged
Conversation
This was referenced Jul 29, 2026
The routine currency bump #48 deferred on the release-age gate. Both versions published 2026-07-28T19:41Z and were 27.0 hours old when this landed, clearing pnpm 11's default `minimum-release-age` of 1440 minutes - so no `minimumReleaseAgeExclude` bypass was written, which was #48's stated acceptance criterion. `pnpm-workspace.yaml` is untouched by this commit. While confirming the gate, the "pnpm 11 default is 1440 minutes" claim was re-derived rather than taken on trust, because `pnpm config get minimumReleaseAge` reports `undefined` and that reads like "no policy". It is not: pnpm 11.17.0's own defaults table carries `"minimum-release-age": 24 * 60, // 1 day` under the kebab-case key. The `config get` answer only reports what is explicitly set. They move together on purpose: `@cloudflare/vitest-pool-workers@0.19.0` hard-pins `wrangler@4.115.0` (0.18.8 pinned 4.114.0), so a split bump cannot resolve. Peer requirements are unchanged across it, and `vitest` stayed at 4.1.10 as expected. Expect nothing behavioural from it. 0.19.0 adds a `verbose` option on `cloudflareTest()`/`cloudflarePool()` and filters one workerd TLS-teardown log line; this repo needs neither. In particular it does NOT fix the four `@cloudflare/containers` sourcemap warnings `pnpm preview:test` prints - re-checked here, and 0.3.7 (2026-06-04) is still the newest release, still shipping a `dist/` whose maps point at a `src/` the tarball omits. Gate: `pnpm run verify` exit 0 - app 1249 passed / 3 skipped, worker 12, container 3, matching the pre-bump baseline exactly. `wrangler types --check` reports `worker-configuration.d.ts` up to date under 4.115.0, so the bump changed no generated types. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GjMSePtN9aTgr8EtZp66k1
wormeyman
force-pushed
the
deps/wrangler-4.115
branch
from
July 30, 2026 05:37
fdaefb5 to
90a941b
Compare
wormeyman
added a commit
that referenced
this pull request
Jul 30, 2026
Verified locally and in CI, and the archive itself was opened by two readers other than the one the test uses. ## The ZIP output is byte-identical across the swap Generated the real artifact both ways (jszip on `main`, client-zip on this branch) for the `Default` preset and compared with **Info-ZIP `unzip`** and **Python `zipfile`** - neither of which is jszip, the reader the spec uses: ``` unzip -t: "No errors detected in compressed data" for BOTH archives ``` | entry | before | after | bytes identical | | --- | --- | --- | --- | | `map-gen-settings.json` | 2936 B | 2936 B | **yes** | | `map-settings.json` | 3806 B | 3806 B | **yes** | | `Default.txt` | 798 B | 798 B | **yes** | Entry **names, order and bodies all identical**; both archives `Stored` at 0%, confirming jszip was not compressing either, so the pako 1.x payload was pure waste. Archive total 7888 -> 7936 B (+48, central-directory layout). Also checked the contents against the exporters directly - with no zip library in the loop - and `Default.txt` is verbatim equal to the `builtin-presets.json` fixture. ## No `eval`, no Node builtins, no new warnings `pnpm vp build` exit 0 and **zero warnings**. Scanning the emitted bundle: | marker | count in `dist` | | --- | --- | | `eval(` / `new Function(` | **0** | | `jszip` / `JSZip` | **0** | | `setImmediate`, `readable-stream`, `_tr_stored_block` | **0** | | `require(`, `node:fs`, `node:path`, `process.nextTick`, `Buffer.from` | **0** | | `incorrect header check` (pako) | **1** - the codec's pako 3.0.1 correctly remains | `public/_headers` and `vite.config.ts` are untouched: CSP is still `script-src 'self' https://static.cloudflareinsights.com` with no `unsafe-eval`, and **no `build.rollupOptions.onLog` suppression was added**. Upstream, `client-zip@2.5.0` is 6.4 kB of single-file ESM, MIT, **zero runtime dependencies**, and its tarball contains no `eval`, `new Function`, `require(` or `node:*` import. ## Bundle size re-measured, not taken from the description Built both branches here: **302.07 kB -> 211.44 kB raw (-90.64 kB, -30.0%)**, gzip -26.7%. Matches the claim. ## Gate - Local `pnpm run verify` exit **0** in 60s on the rebased tree: format 316, lint+type 301, `check:vue` clean, app **1251 passed / 3 skipped** (+2 as described), worker 12. - CI `verify`: **pass** on head `39a5890`, rebased onto `605a4cc` so it ran against a `main` containing both #51 and #52 - including #52's new `check:vue` phase. - `jszip` is in `devDependencies` and `client-zip` in `dependencies`; `pnpm install --frozen-lockfile` clean. ## One thing the PR missed `test/actionBar.spec.ts:72` still carries a jszip-specific comment - "buildZip -> JSZip.generateAsync resolves across macrotasks/setImmediate, which flushPromises (microtasks only) does not drain". The 100ms real-timer wait it justifies still works, so nothing fails, but the comment now explains the code by naming a dependency the app no longer bundles. Left as-is rather than widened into this PR; worth a one-line follow-up.
wormeyman
added a commit
that referenced
this pull request
Jul 30, 2026
…RULE, not the fields (#57) Verified locally and in CI, and the anti-vacuity control was tested by breaking it. ## The `+3` control is genuinely load-bearing - proven, not assumed This repo has a documented history of confirmations that turned out vacuous, so I sabotaged the substitution rather than trusting the assertion. Replacing the game-field lookup with one that never matches - i.e. simulating every lookup silently falling through to our own field: | test | with substitution dead | | --- | --- | | "substituting the game's own elevation and cliffiness does not move a single cell" | **still passes** | | "and the substitution really is live - a `+3` elevation bias does move cells" | **FAILS**: `AssertionError: expected 0 to be greater than 5` | So the headline assertion *would* have passed vacuously, and the `+3` control is exactly what catches it. Restored and re-confirmed 9/9 green. `expect(game.size).toBeGreaterThan(500)` is a second, independent guard against an empty placement set making the equality trivial. ## Provenance `test/fixtureProvenance.spec.ts` passes (4/4). Both new fixtures carry entries with `factorioVersion: "2.1.12"` and concrete `evidence` naming the capture script and recording that `refs:sync --check` reported in-sync at capture time - so neither lands as `unknown`, and the spec's `unknown` cap is not touched. ## Gate - Local `pnpm run verify` exit **0** in 60s on the exact tree that lands (`5399b6f`): format 316, lint+type 301, `check:vue` clean, app **1255 passed / 3 skipped**, worker 12. - CI `verify`: **pass** (4m41s). The branch was updated **twice** so the run tests the real target - it now contains #51, #52, #55 and #59, not the older `main` the first run saw. - No `src/` change, so nothing shipped to users; the new spec needs no Factorio at runtime because the fixtures are committed, which is why CI can run it. ## Two notes, neither blocking - The description reads as though `test/vulcanusOreCliffSeparation.spec.ts` is new. It is not - it already existed on `main` at 222 lines and this extends it to 597 (3 -> 7 `it` blocks at the top level, 9 tests total), which is why the file count stays 143 and the suite moves +4 rather than +9. - Re-deriving the binary reading and the statistics was explicitly out of scope for this pass, so the `0x1016229b4` / `0x101625038` disassembly claims and the Poisson figures are **recorded as the author's measurements, not independently reproduced here**. What was checked is that the code is gated, the fixtures have provenance, and the assertions can fail.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #48 - the bump it deferred on the release-age gate.
The gate is clear
Both published 2026-07-28T19:41Z and were 27.0 hours old when this landed, against pnpm 11's default
minimum-release-ageof 1440 minutes. #48's acceptance criterion was "nominimumReleaseAgeExcludeblock appears in the diff" - none did, andpnpm-workspace.yamlis untouched by this commit.While confirming that, the "pnpm 11 default is 1440 minutes" claim was re-derived rather than trusted, because
pnpm config get minimumReleaseAgereportsundefined- which reads like "there is no policy here". It is not. pnpm 11.17.0's own defaults table carries"minimum-release-age": 24 * 60, // 1 dayunder the kebab-case key;config getonly reports what is explicitly set. Worth knowing before someone concludes the guard is off.They move together
@cloudflare/vitest-pool-workers@0.19.0hard-pinswrangler@4.115.0(0.18.8 pinned 4.114.0), so a split bump cannot resolve. Peers are unchanged across it andviteststayed at 4.1.10.Expect nothing behavioural
0.19.0 adds a
verboseoption oncloudflareTest()/cloudflarePool()and filters one workerd TLS-teardown log line. This repo needs neither - it is a keep-current bump, not a feature.It does not fix the four
@cloudflare/containerssourcemap warningspnpm preview:testprints. Re-checked here:0.3.7(2026-06-04) is still the newest release and its published tarball still ships adist/whose maps point at asrc/it does not include, with nosourcesContent. Upstream packaging bug, unchanged.Gate
pnpm run verifyexit 0:Identical to the pre-bump baseline.
wrangler types --checkreportsworker-configuration.d.tsup to date under 4.115.0, so the bump changed no generated types.Found by the dependency audit of 2026-07-29.
🤖 Generated with Claude Code
https://claude.ai/code/session_01GjMSePtN9aTgr8EtZp66k1