Repository navigation
Update Effect to 4.0.0 - #66
Conversation
There was a problem hiding this comment.
ℹ️ No critical issues. There are two documentation nits.
Reviewed changes
This review covers the change from Effect 4.0.0-rc.118 to 4.0.0 and the updates to the Array.partition call sites.
- Effect pins moved to
4.0.0.effectand@effect/platform-nodechanged inpackage.json,pnpm-lock.yaml, and the Packref lock entry. The upstream tageffect@4.0.0exists, sopackref installcan resolve the entry. Array.partitiondestructuring swapped. All five call sites ininstall.ts,remove.ts, andsync.tsnow read[passes, fails]. This agrees with the4.0.0implementation ineffect/src/Array.ts. Inrc.118and4.0.0,Effect.partition,Option.partition,Record.partition, andArray.separatealso swap their order.src/does not use them.- The
tscclaim is not true for one site. Atinstall.ts:156, both sides of the partition arePackageEntry, so the type checker cannot find a wrong order. I reverted only that swap as a test:tscstayed clean, and 10 tests failed in the twoinstall.test.tsfiles. The tests cover this site. - adamantite's Effect copy stays on
rc.116. The lockfile entry that was kept by hand is the same as onmain, andpnpm install --frozen-lockfileaccepts it.
With a temporary minimumReleaseAge: 0 override, these all pass: check, tsc --noEmit, analyze, the unit tests (293 passed), and build:verify.
ℹ️ ADR 0001 still gives the old Array.partition order
docs/adr/0001-use-packref-for-dependency-source-inspection.md tells contributors and agents that "the locked Effect version" returns "transformed failure and success arrays as a tuple". After this PR, the locked version returns successes first. An agent that follows the ADR can write [failures, successes]. If both sides have the same type, as at install.ts:156, tsc does not find the error.
Technical details
# ADR 0001 describes the rc-era `Array.partition` tuple order
## Affected sites
- docs/adr/0001-use-packref-for-dependency-source-inspection.md:21-22 — "returns transformed failure and success arrays as a tuple" states the `rc.118` order `[excluded, satisfying]`.
## Required outcome
- The ADR states the `4.0.0` order: `[passes, fails]` (success array first, failure array second).claude-opus-5-5 | 𝕏
There was a problem hiding this comment.
Important
The fresh lockfile resolution makes the repository check command fail.
Reviewed changes
This review covers the lockfile rebuilt after the prior Pullfrog review.
- Re-resolved the dependency graph.
pnpm-lock.yamlrefreshed transitive packages, including Redis, Vite, and Changesets dependencies. - Changed Adamantite's nested Effect graph. Adamantite still uses
effect@4.0.0-rc.115, but its@effect/platform-node-sharedresolution moved to stable4.0.0.
gpt-5.6-terra | 𝕏
There was a problem hiding this comment.
ℹ️ No new issues found in this delta. A prior documentation follow-up remains open.
Reviewed changes
This review covers the Adamantite 0.42.0 update since the prior Pullfrog review.
- Updated Adamantite to stable Effect dependencies. The nested
effect,@effect/platform-node, and shared platform package now resolve to compatible stable4.0.0releases. - Refreshed the development tool dependency graph. The lockfile updates Adamantite and its resolved tooling dependencies.
gpt-5.6-terra | 𝕏
There was a problem hiding this comment.
ℹ️ No new issues found in this delta. The prior documentation follow-up remains open.
Reviewed changes
This review covers the pnpm workspace policy added since the prior Pullfrog review.
- Excluded Adamantite from the release-age policy. The new
pnpm-workspace.yamlpermits the maintainedadamantiteupdate while it keeps the default policy for all other packages. - Restored normal frozen installs.
pnpm install --frozen-lockfile --prefer-offlineandpnpm run checkboth passed with the committed configuration.
gpt-5.6-terra | 𝕏
Effect 4.0.0 returns `[passes, fails]` from `Array.partition`, so the destructuring order at each call site is swapped. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
adamantite 0.42.0 runs on Effect 4.0.0, so `adamantite check` and `adamantite analyze` no longer crash on a mixed Effect install. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
We maintain adamantite, so a new release does not need the one-day waiting period before Packref can install it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…t line ADR 0001 now states that `Array.partition` returns `[passes, fails]`. The pending changeset no longer names `4.0.0-rc.118`, so the release notes give only one Effect version. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
5da0335 to
f6ba9c4
Compare

Effect v4 has a stable release now, so we move from
4.0.0-rc.118to4.0.0. The one breaking change that affects us:Array.partitionnow returns[passes, fails]instead of[fails, passes]. All five call sites have the destructuring swapped. The type checker catches four of them. Atinstall.ts:154, both sides have the same type, so only theinstalltests catch a wrong order there. ADR 0001 now states the new order. The Packref reference for Effect is synced to4.0.0too.adamantite moves to 0.42.0 too. 0.41.0 pinned Effect
rc.115, and a fresh resolve paired it with@effect/platform-node-shared@4.0.0, soadamantite checkandadamantite analyzecrashed. 0.42.0 runs on Effect 4.0.0, so the lockfile now holds a single Effect version.A new
pnpm-workspace.yamlexempts adamantite from pnpm 12's default one-dayminimumReleaseAge. We maintain adamantite, so its new releases install right away. All other packages still need to be one day old.Verified locally:
adamantite check,adamantite analyze, unit tests, andbuild:verifypass.Changes made by Claude Opus 5.5 in Claude Code.
🤖 Generated with Claude Code