@alashi/cli 0.8.0 → 0.8.1

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": "@alashi/cli",
3
- "version": "0.8.0",
3
+ "version": "0.8.1",
4
4
  "description": "alashi host: install, manage, and run Claude Code-powered apps",
5
5
  "type": "module",
6
6
  "license": "MIT",
@@ -29,14 +29,14 @@
29
29
  "templates"
30
30
  ],
31
31
  "dependencies": {
32
- "@alashi/apps-sdk": "^0.5.0",
32
+ "@alashi/apps-sdk": "^0.6.0",
33
33
  "@hono/node-server": "^2.1.1",
34
34
  "commander": "^14.0.0",
35
35
  "croner": "^10.0.1",
36
36
  "hono": "^4.13.2",
37
37
  "semver": "^7.8.5",
38
38
  "zod": "^4.4.3",
39
- "@alashi/provider-claude": "^0.2.0"
39
+ "@alashi/provider-claude": "^0.2.1"
40
40
  },
41
41
  "devDependencies": {
42
42
  "@types/node": "^26.2.0",
@@ -29,13 +29,22 @@ Beside the manifest: `routes` (fetch-style `(Request, ctx) => Response`) and
29
29
  `jobHandlers` (`{ [name]: (ctx) => Promise<void> }`).
30
30
 
31
31
  Known gap: `onInstall`/`onUpdate` exist in the SDK but the host never calls
32
- them — create DB schema lazily (`CREATE TABLE IF NOT EXISTS` on first open).
32
+ them — so nothing runs at install time and the app owns its own schema. Schema
33
+ lives in ordered `.sql` files in `migrations/` (`001-init.sql`,
34
+ `002-add-....sql`), applied by `runMigrations(db, join(import.meta.dirname,
35
+ 'migrations'))` every time the DB is opened. It is forward-only and tracked in
36
+ `PRAGMA user_version`: a schema change is **a new numbered file**, never an
37
+ edit to one that has already been applied, and there are no down-migrations.
38
+ Statements that cannot run inside a transaction — notably
39
+ `PRAGMA journal_mode = WAL` — must not live in a migration file; set those on
40
+ the connection before calling `runMigrations`.
33
41
 
34
42
  ## Runtime surface (`ctx`)
35
43
 
36
44
  - `ctx.dataDir` — the **only** writable directory. SQLite DB and files go
37
45
  here (`node:sqlite` `DatabaseSync`). Treat the repo itself as read-only at
38
- runtime.
46
+ runtime — the DB lives in `ctx.dataDir`, but the `migrations/` files that
47
+ shape it are code and are read from the app repo (`import.meta.dirname`).
39
48
  - `ctx.config` — merged config (readonly).
40
49
  - `ctx.state` — small key/value store; `ctx.logger` — log here, not console.
41
50
  - `ctx.ai.createSession()` — an agent session, pre-scoped by the host
@@ -18,6 +18,7 @@ your changes are live.
18
18
  | File | What it is |
19
19
  |---|---|
20
20
  | `index.mjs` | The app: manifest, API routes, job handlers |
21
+ | `migrations/` | Ordered `.sql` files — the DB schema, applied at DB open |
21
22
  | `ui/index.html` | The web UI, served at `/app/__APP_NAME__/` |
22
23
  | `AGENTS.md` | The platform contract, written for coding agents working in this repo |
23
24
 
@@ -27,7 +28,12 @@ your `routes` handler, so you can also server-render pages.
27
28
  ## What the app gets
28
29
 
29
30
  - **`ctx.dataDir`** — the only writable directory; put your SQLite DB and
30
- files here (the template creates `app.db` on first request)
31
+ files here (the template opens `app.db` there on first request and applies
32
+ `migrations/` to it)
33
+ - **`migrations/`** — the schema, as ordered `.sql` files applied by
34
+ `runMigrations` at DB open: forward-only, tracked in `PRAGMA user_version`.
35
+ To change the schema, add the next numbered file (`002-...sql`) — never edit
36
+ one that has already run
31
37
  - **`ctx.state`** — small key/value store (`state.json`)
32
38
  - **`ctx.config`** — `configDefaults` merged with the user's per-app config
33
39
  - **`ctx.ai`** — AI sessions through the host; the Chat page uses the host's
@@ -1,12 +1,12 @@
1
1
  import { join } from 'node:path';
2
2
  import { DatabaseSync } from 'node:sqlite';
3
- import { defineApp } from '@alashi/apps-sdk';
3
+ import { defineApp, runMigrations } from '@alashi/apps-sdk';
4
4
 
5
5
  export default defineApp({
6
6
  name: '__APP_NAME__',
7
7
  version: '0.1.0',
8
8
  description: 'An alashi app',
9
- sdkVersion: '^0.5.0',
9
+ sdkVersion: '^0.6.0',
10
10
  ui: 'ui',
11
11
  configDefaults: {
12
12
  greeting: 'What should we work on?',
@@ -27,11 +27,12 @@ export default defineApp({
27
27
  routes: (ctx) => {
28
28
  // The app's own SQLite database, living in its data dir.
29
29
  const db = new DatabaseSync(join(ctx.dataDir, 'app.db'));
30
- db.exec(`CREATE TABLE IF NOT EXISTS notes (
31
- id INTEGER PRIMARY KEY AUTOINCREMENT,
32
- text TEXT NOT NULL,
33
- created_at TEXT NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%SZ', 'now'))
34
- )`);
30
+ // Schema comes from the ordered .sql files in this repo's migrations/
31
+ // (not ctx.dataDir), applied forward-only at DB open. A schema change
32
+ // ships as a new numbered file — never as an edit to an applied one.
33
+ // Pragmas that cannot run inside a transaction (journal_mode) go here,
34
+ // before the call, not into a migration file.
35
+ runMigrations(db, join(import.meta.dirname, 'migrations'), { logger: ctx.logger });
35
36
 
36
37
  return async (req) => {
37
38
  const url = new URL(req.url);
@@ -0,0 +1,7 @@
1
+ -- Applied once, then never touched again. Schema changes ship as a new
2
+ -- numbered file (002-..., 003-...), never as an edit to this one.
3
+ CREATE TABLE notes (
4
+ id INTEGER PRIMARY KEY AUTOINCREMENT,
5
+ text TEXT NOT NULL,
6
+ created_at TEXT NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%SZ', 'now'))
7
+ );
@@ -4,6 +4,6 @@
4
4
  "type": "module",
5
5
  "main": "index.mjs",
6
6
  "dependencies": {
7
- "@alashi/apps-sdk": "^0.5.0"
7
+ "@alashi/apps-sdk": "^0.6.0"
8
8
  }
9
9
  }