From a83a744b0a02d13545ec77291c9d88e17c87ffd6 Mon Sep 17 00:00:00 2001 From: Seenu K Date: Wed, 12 Aug 2026 01:42:22 +0530 Subject: [PATCH] Pin eigen_flutter ^0.4.0, the first shell that reads a session A scaffold writes both halves of a project and the worker half is this repository's line, so the shell it installs has to speak that line's socket. Every published eigen_flutter 0.3.x constrains eigen_api ^0.2.0, which cannot decode a 0.3.x engine's session at all, so the old pin would have resolved, compiled and then failed to render a game on first run. 0.4.0 is published, so the pin can cross the line, which this repository deliberately requires a human to do. The Dart API never broke here: the templates only read GameContentContext, and 0.4.0 added a field to it. Co-Authored-By: Claude Opus 5 --- .changeset/pin-the-session-shell.md | 9 +++++++++ packages/create-eigen-game/src/index.ts | 18 +++++++++++------- .../create-eigen-game/test/scaffold.spec.ts | 2 +- 3 files changed, 21 insertions(+), 8 deletions(-) create mode 100644 .changeset/pin-the-session-shell.md diff --git a/.changeset/pin-the-session-shell.md b/.changeset/pin-the-session-shell.md new file mode 100644 index 0000000..64850f9 --- /dev/null +++ b/.changeset/pin-the-session-shell.md @@ -0,0 +1,9 @@ +--- +"create-eigen-game": minor +--- + +Generated apps now install `eigen_flutter@^0.4.0`, the first shell that speaks the engine's session-snapshot wire. + +This pin is usually only an improvement deferred until a human confirms the templates still compile, but not this time. A scaffold writes both halves of a project, and the worker half is this repository's own line, so the shell it installs has to read that line's socket. Every published `eigen_flutter` 0.3.x constrains `eigen_api: ^0.2.0`, which cannot decode a 0.3.x engine's session at all, so a scaffold left on the old pin would resolve cleanly, compile cleanly, and then fail to render a game on first run. + +The **Scaffolded project builds** job asserts both halves of the claim, and this is exactly the release where the two come apart: `flutter analyze` and `flutter test` cover the Dart API, which never broke here (the templates read `GameContentContext`, and 0.4.0 only added a field to it), while the `eigen_api` line check off the generated `pubspec.lock` covers the wire, which is the half that did. diff --git a/packages/create-eigen-game/src/index.ts b/packages/create-eigen-game/src/index.ts index 7a7ae5d..0a6d153 100644 --- a/packages/create-eigen-game/src/index.ts +++ b/packages/create-eigen-game/src/index.ts @@ -192,19 +192,23 @@ const engineVersion = engineRange((JSON.parse(readFileSync(resolve(packageRoot, * selected, and the generated app would not compile. * * A caret RANGE rather than an exact version, so it still improves without a - * republish: `flutter pub add eigen_flutter@^0.3.0` already picks the newest - * 0.3.x at scaffold time, which is the part the pub.dev lookup was duplicating. - * What it deliberately cannot do is cross to 0.4.x, the one move that needs a + * republish: `flutter pub add eigen_flutter@^0.4.0` already picks the newest + * 0.4.x at scaffold time, which is the part the pub.dev lookup was duplicating. + * What it deliberately cannot do is cross to 0.5.x, the one move that needs a * human to confirm the templates still compile. * * Staleness is therefore a failing check rather than a broken scaffold: this is * only ever a release behind, never wrong. * - * Raised to 0.3.0 because the notification icon moved into `eigen_flutter`'s - * Android plugin: the scaffold stopped shipping `ic_notification.xml`, so a - * game resolving 0.2.x would reference a drawable nothing provides. + * Raised to 0.4.0 with the engine's session-snapshot wire. This is the one kind + * of bump that is not merely an improvement: a scaffold writes both halves, and + * the worker half is this repository's own line, so the shell it installs has to + * speak that line's socket. `eigen_flutter` 0.4.0 is the first that does, and + * every 0.3.x pins `eigen_api: ^0.2.0`, which cannot read a 0.3.x engine at all. + * A scaffold pinning 0.3.x would therefore resolve, compile, and then fail to + * render a game, which is the worst of the three. */ -const flutterClientVersion = "^0.3.0"; +const flutterClientVersion = "^0.4.0"; const gameSlug = (value: string): string => { if (!/^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(value)) { diff --git a/packages/create-eigen-game/test/scaffold.spec.ts b/packages/create-eigen-game/test/scaffold.spec.ts index 5d8c4b4..caeff09 100644 --- a/packages/create-eigen-game/test/scaffold.spec.ts +++ b/packages/create-eigen-game/test/scaffold.spec.ts @@ -195,7 +195,7 @@ describe("scaffoldGame", () => { // release on that line, which is the part a scaffold-time pub.dev lookup // was duplicating. Crossing to the next line is the move that needs the // `scaffold` CI job to confirm the templates still compile. - expect(run).toHaveBeenCalledWith("flutter", ["pub", "add", "eigen_flutter@^0.3.0", "firebase_core@^4.9.0", "firebase_messaging@^16.2.2"], expect.stringMatching(/\/app$/)); + expect(run).toHaveBeenCalledWith("flutter", ["pub", "add", "eigen_flutter@^0.4.0", "firebase_core@^4.9.0", "firebase_messaging@^16.2.2"], expect.stringMatching(/\/app$/)); // A separate `pub add` (rather than folded into the call above) so a // failure here is legible on its own, and because these are dev // dependencies (`dev:` prefix) while the engine/Firebase packages above