Scaffold eigen_flutter ^0.6.0 alongside the 0.4.x engine

.changeset/scaffold-flutter-0-6.md

@@ -0,0 +1,19 @@
+---
+"create-eigen-game": minor
+---
+
+Install `eigen_flutter@^0.6.0` into the app half, matching the engine's 0.4.x line.
+
+This is a required pairing rather than an improvement. The 0.4.x engine takes
+`cursor` as an opaque string and returns `nextCursor` on every paged response,
+and `eigen_flutter` 0.6.0 is the first shell that pins `eigen_api: ^0.4.0` and
+can read it. Everything below pins `eigen_api: ^0.3.0` or older, so a scaffold
+left on `^0.4.1` installed the engine's current line beside a shell that could
+not read a single paged list from it: it resolved, it compiled, and then the
+lobby and the history screen were empty. 0.5.0 is skipped for the same reason,
+being a web-design release that still speaks the 0.3.x wire.
+
+Closes the window opened by the engine's own 0.4.0 release: because
+`updateInternalDependencies` republishes this package whenever the engine
+version moves, the scaffolder had already gone out pairing a 0.4.x worker with a
+0.4.1 shell.

packages/create-eigen-game/src/index.ts

@@ -213,8 +213,26 @@ const engineVersion = engineRange((JSON.parse(readFileSync(resolve(packageRoot,
  * still resolve it, but `^0.4.0` also still resolves 0.4.0, where the parameter
  * does not exist and the scaffold would not compile. The floor is what makes
  * the generated code and the installed shell agree.
+ *
+ * Raised to 0.6.0 with the engine's opaque pagination cursors, and this is the
+ * same *required* kind of bump the 0.4.0 note describes rather than an
+ * improvement. The 0.4.x engine line takes `cursor` as an opaque string and
+ * returns `nextCursor` on every paged response; `eigen_flutter` 0.6.0 is the
+ * first shell that pins `eigen_api: ^0.4.0` and can read it. Everything below
+ * that pins `eigen_api: ^0.3.0` or older, so a scaffold left on `^0.4.1` would
+ * install the engine's current line beside a shell that cannot read a single
+ * paged list from it: it resolves, it compiles, and then the lobby and history
+ * are empty. 0.5.0 is skipped for the same reason, being a web-design release
+ * that still speaks the 0.3.x wire.
+ *
+ * Note that this floor and the engine range are raised in one commit on
+ * purpose. The scaffolder writes both halves, and `updateInternalDependencies`
+ * republishes this package whenever the engine version moves, so between an
+ * engine line crossing and this line moving there is a published scaffolder
+ * that pairs a new worker with an old shell. That window is real and this is
+ * what closes it.
  */
-const flutterClientVersion = "^0.4.1";
+const flutterClientVersion = "^0.6.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.4.1", "firebase_core@^4.9.0", "firebase_messaging@^16.2.2"], expect.stringMatching(/\/app$/));
+    expect(run).toHaveBeenCalledWith("flutter", ["pub", "add", "eigen_flutter@^0.6.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