Cottontail 0.5.0 ships without cottontail-core, breaking mainProcess cottontail builds

Found a workaround that unblocks both dev and build on stable, without touching the store.

The 0.5.0 archive isn't what changed — it's Hutch. My machine self-updated from 0.24.3 to 0.26.0 this morning and the error started right then. Hutch 0.26.0 expects bin/cottontail-core inside the Cottontail release it bundles as the app runtime, and that layout only exists from 0.6.0 on. Electrobun 2.0.1 pins 0.5.0 (COTTONTAIL_VERSION in the devkit's api/shared/cottontail-version.ts), so every 2.0.1 project with mainProcess: "cottontail" breaks as soon as Hutch updates itself. Hutch 0.24.3 packages the very same 0.5.0 release fine.

Pin Hutch for the project:

hutch self pin 0.24.3

That adds a pragma to the top of hutch.config.ts:

// @hutch cli=0.24.3

After that hutch --version reports 0.24.3 inside the project, and both hutch electrobun dev and hutch electrobun build --env=stable complete (verified on macOS arm64: app launches, .app + .dmg produced). Commit the pragma, otherwise CI that installs Hutch from the install script gets 0.26.0 and hits the same error.

I haven't tried 0.25.x, so 0.24.3 is simply the last version I know works.

For the maintainers, either of these would fix it properly: have Hutch ≥ 0.26 fall back to the single-binary layout when the paired Cottontail is < 0.6.0, or cut a stable Electrobun that pairs Cottontail 0.6.0. The pin can be dropped once one of those lands.

Follow-up: you can also get past this by moving forward instead of pinning Hutch, as long as the Electrobun beta line is acceptable.

It is a pairing mismatch, not a bad archive. Hutch ≥ 0.26 expects the split runtime layout (cottontail, cottontail-core, cottontail-stdlib), while the newest stable Electrobun (2.0.1) still pairs Cottontail 0.5.0, which only ships bin/cottontail. The 2.0.2 betas pair a Cottontail with the new layout, so bumping Electrobun instead of holding Hutch back makes the error go away.

1. Drop the pin. hutch self pin has no unpin, so delete the pragma from the top of hutch.config.ts:

   // @hutch cli=0.24.3

2. Point the project at the beta in hutch.config.ts:

   electrobun: {
     version: "2.0.2-beta.27",
   },

3. Re-project the devkit:

   hutch electrobun prepare

   api/shared/cottontail-version.ts in the devkit should now read 0.7.0-canary.10, and that release's bin/ contains cottontail-core.

One thing that bit me afterwards: Cottontail 0.7 makes its stdlib opt-in per capability, and the build only includes what its scan can see in the bundle. fetch decompressing a gzip/zstd response is invisible to that scan, so every request to a server that compresses its responses failed at runtime:

Error: Decompression error: ZstdDecompressionError {
  code: "ZstdDecompressionError",
  cause: Error: Cottontail capability "compression" is unavailable. Add "compression" to build.cottontail.capabilities in electrobun.config.ts.,
}

Declaring it explicitly fixes that:

build: {
  mainProcess: "cottontail",
  cottontail: {
    entrypoint: "src/bun/index.ts",
    capabilities: ["compression"],
  },
},

With those changes Hutch 0.26.0 runs hutch run dev and hutch run build with no pin. Verified on macOS arm64: the app launches, fetch and WebSocket work, and the .app and .dmg are produced and install fine. I haven't built Windows or Linux on this combination yet.

The trade-off is worth stating plainly: this ships Cottontail 0.7.0-canary.10 as the app runtime — a canary inside a production bundle — and there is still no stable Electrobun pairing Cottontail ≥ 0.6.0 (the latest dist-tag is 2.0.1). Until a stable 2.0.2 lands, the choice is between pinning an older Hutch and running the Electrobun beta.