Pin eigen_flutter ^0.4.0

.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.

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)) {

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