create-theokit 3.0.9 → 3.0.12

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "create-theokit",
3
- "version": "3.0.9",
3
+ "version": "3.0.12",
4
4
  "type": "module",
5
5
  "description": "Scaffold a new TheoKit project",
6
6
  "repository": {
@@ -14,7 +14,7 @@ tone instruction in this file quietly makes `usePersonality` do nothing. Tone be
14
14
 
15
15
  ## Why this file is here and not at the root
16
16
 
17
- This project installs `@theokit/sdk@^5.3.0`, where **both** locations work: 5.x added a root
17
+ This project installs `@theokit/sdk@^5.9.2`, where **both** locations work: 5.x added a root
18
18
  `THEO.md` (`usetheokit/theokit-sdk#531`) at priority 55, and `.theokit/THEO.md` at 60 still wins a
19
19
  conflict. The scaffold keeps the file here because it wins, not because the root is unreadable.
20
20
 
@@ -25,10 +25,19 @@ halves expired: 5.5.0 is `latest`, and the template's pin moved to `^5.3.0` beca
25
25
  parity surface this framework advertises is absent from 4.x. A scaffold that hands a new project an
26
26
  SDK delivering none of that, with nothing saying so, is the defect the pin change closes.
27
27
 
28
- The floor is 5.3 rather than 5.0 because the framework's persistence barrel re-exports six names that
28
+ The floor was 5.3 rather than 5.0 because the framework's persistence barrel re-exports six names that
29
29
  5.0.0 does not have — measured with controls, 1 of 7 at 5.0.0 and 7 of 7 from 5.3.0 — so the range had
30
30
  to name a version that can actually build it.
31
31
 
32
+ It moved to 5.9.2 on 2026-09-28, for a reason that is about deployment rather than about exports. Every
33
+ version below it resolves a path at module scope in `internal/providers/catalog-loader.ts`, and Cloudflare
34
+ executes the top-level module during validation — so a Workers deploy of a project declaring an agent was
35
+ refused outright with code 10021. The framework carried a compensation for it in the `wrangler.toml` it
36
+ generates, substituting a literal for `import.meta.url`; that made a broken dependency appear to work and
37
+ would have covered the next one with the same vice in silence. 5.9.2 fixes the cause, measured on the
38
+ published tarball — 0 of 254 executable files resolve a path at module scope — so the compensation is gone
39
+ and the requirement is declared here instead, where a reader can see it.
40
+
32
41
  Two more things worth knowing if you do move it once 5.x is stable:
33
42
 
34
43
  - The root spec sets `followImports: true`, this one does not. `@file` references resolve there and
@@ -16,9 +16,9 @@
16
16
  "typecheck": "tsc --noEmit"
17
17
  },
18
18
  "dependencies": {
19
- "theokit": "^0.73.0",
20
- "@theokit/agents": "^12.1.0",
21
- "@theokit/sdk": "^5.3.0",
19
+ "theokit": "^0.74.1",
20
+ "@theokit/agents": "^15.0.2",
21
+ "@theokit/sdk": "^5.9.2",
22
22
  "@theokit/ui": "^1.1.0",
23
23
  "@usetheo/ui": "^0.26.0",
24
24
  "lucide-react": "^0.469.0",