@stardeck-customer-apps/compose 0.1.0 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/SKILL.md CHANGED
@@ -23,17 +23,39 @@ Compose turns that declaration into the code Next.js actually builds:
23
23
  npx stardeck-compose [--enabled=a,b,c] [--prune] [--cwd=<repo root>]
24
24
  ```
25
25
 
26
- Run it from the repo root (the directory holding `apps/web`). Today you invoke
27
- it manually — `npx stardeck-compose` before `next dev` / `next build` / your
28
- typecheck — after changing any `module.json`. The `predev` / `prebuild` /
29
- `pretypecheck` / `pretest` wiring that makes this automatic has not landed yet.
30
-
31
- **Caveat: compose has no platform database.** It composes from `module.json`
32
- alone, so Module data-store bindings resolve to none (`module-datastores.gen.ts`
33
- comes out empty) and every Module's registry version reads `unreleased`. An app
34
- whose platform-side rail resolved real data-store bindings must not run compose
35
- until the consumer wiring supplies them — compose would otherwise overwrite the
36
- bindings with nothing.
26
+ Run it from the repo root (the directory holding `apps/web`). The Blueprint
27
+ island wires `predev`, `prebuild`, `prebuild:check`, `prelint`, `pretypecheck`
28
+ and `pretest` in `apps/web/package.json` to `stardeck-compose --cwd ../..`, and
29
+ a platform migration adds the same hooks to every app, so every
30
+ `npm run dev|build|lint|typecheck|test` composes first. A repo with no
31
+ `apps/web/src/modules` is a valid app: it composes to empty registries and a
32
+ header-only stub ignore list.
33
+
34
+ Needs `typescript` >=5 <7 (it parses your route entries with the compiler API).
35
+
36
+ **compose has no platform database.** The two facts the platform rail reads from
37
+ one — the data stores connected to the app, and each Module's install row — come
38
+ from `apps/web/stardeck.compose.json` instead:
39
+
40
+ ```jsonc
41
+ {
42
+ "connectedStores": [
43
+ { "storeId": "ds_123", "slug": "media", "bindingKey": null, "accessLevel": "write" }
44
+ ],
45
+ "installs": {
46
+ "pos": { "installedVersion": "7.49.0", "datastoreBindings": { "media": "ds_123" } }
47
+ }
48
+ }
49
+ ```
50
+
51
+ The platform writes it before every deploy, every dev-server start or restart,
52
+ and every rail reconcile; write it by hand to compose locally against real
53
+ stores. It is an input, not a result — compose still resolves and
54
+ validates the bindings itself. Without the file, `module-datastores.gen.ts`
55
+ composes empty and every registry version reads `unreleased`, so an app with
56
+ bound stores must not compose without it. A malformed file is a hard error, never
57
+ a silent fallback. It holds deployment facts: gitignore it (`apps/web/.gitignore`:
58
+ `stardeck.compose.json`).
37
59
 
38
60
  - `--enabled` — comma-separated **feature** Module names. Unset composes every
39
61
  installed Module. Library and contract Modules are always composed. A name
@@ -57,3 +79,12 @@ bindings with nothing.
57
79
  - `@stardeck-customer-apps/compose/runtime` exports `isModuleEnabledByList`,
58
80
  the single enablement rule, and imports nothing — it is safe in client
59
81
  components.
82
+
83
+ ## Generated ignore list
84
+
85
+ After each run compose rewrites `apps/web/src/app/.gitignore` with one entry per
86
+ stub it emits — stubs are scattered one-per-route and cannot be globbed. Commit
87
+ that file: it is deterministic output, and compose rewrites it only when the set
88
+ of stubs changes, so an unchanged compose leaves `git status` clean. It does not
89
+ list the five `src/*.gen.ts`; a static `src/*.gen.ts` line in `apps/web/.gitignore`
90
+ covers those. Compose refuses to touch the file if line 1 is not its own header.