@plitzi/cli 0.38.3 → 0.38.4

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": "@plitzi/cli",
3
- "version": "0.38.3",
3
+ "version": "0.38.4",
4
4
  "license": "AGPL-3.0",
5
5
  "description": "Command line for Plitzi: scaffold a project that renders a space, a plugin package, or an element of your own.",
6
6
  "files": [
@@ -21,14 +21,14 @@
21
21
  },
22
22
  "sideEffects": false,
23
23
  "dependencies": {
24
- "@plitzi/sdk-authoring": "0.38.3",
24
+ "@plitzi/sdk-authoring": "0.38.4",
25
25
  "chalk": "^6.0.1",
26
26
  "commander": "^15.0.0",
27
27
  "esbuild": "^0.28.2",
28
28
  "fflate": "^0.8.3"
29
29
  },
30
30
  "devDependencies": {
31
- "@plitzi/sdk-shared": "0.38.3",
31
+ "@plitzi/sdk-shared": "0.38.4",
32
32
  "@types/node": "^26.6.4",
33
33
  "eslint": "^9.39.5",
34
34
  "eslint-plugin-import": "^2.32.0",
@@ -5,9 +5,9 @@ description: >-
5
5
  generates: scaffold a project that renders a space, add elements of your own (plugins) to it, create a plugin package,
6
6
  build a plugin into the module + manifest + zip the platform takes, sign in to upload and install it on a space, and
7
7
  edit a space's own server code (its functions) in the project, and take a space on Plitzi out as a self-hosted project
8
- of its own (`create --from`, kept in step with `pull`). Use whenever the task is to start a Plitzi project, create or
9
- change a plugin/custom element, pack, upload or install one, pull/push/try a space's functions, move a space to a
10
- server of its own, or work out which space the CLI is connected to.
8
+ of its own (`create --from`, kept in step with `pull` and `push`). Use whenever the task is to start a Plitzi project,
9
+ create or change a plugin/custom element, pack, upload or install one, pull/push/try a space's functions, move a space
10
+ to a server of its own and back, or work out which space the CLI is connected to.
11
11
  ---
12
12
 
13
13
  # The Plitzi CLI
@@ -20,6 +20,7 @@ a signed-in upload. **Reach for it before writing any of those yourself.**
20
20
  npx @plitzi/cli create my-site # a project that renders a space (--template blank | catalog)
21
21
  npx @plitzi/cli create my-board --from pizarra # a space on Plitzi, as a project that serves it alone
22
22
  npx @plitzi/cli pull # that project brought up to date with its space
23
+ npx @plitzi/cli push # its changes back as the draft (or: push space functions)
23
24
  npx @plitzi/cli add plugin seat-picker legend # elements of your own, in the project you are in
24
25
  npx @plitzi/cli create seat-picker --plugin # a plugin package any space can load
25
26
  npx @plitzi/cli pack plugin # a plugin built, and zipped the way the builder takes it
@@ -28,7 +29,7 @@ npx @plitzi/cli whoami # who the CLI is signed in as, an
28
29
  npx @plitzi/cli data describe public/data/products.json # a JSON file's fields, types and one row — not read whole
29
30
  npx @plitzi/cli upgrade # the project up to this CLI: files, package.json, skills, renames (--write)
30
31
  npx @plitzi/cli upgrade skills --write # only one part: files | packages | skills | renames
31
- npx @plitzi/cli explain navigate # what a name means: element, step, trigger, problem or suggestion code (--list steps)
32
+ npx @plitzi/cli explain navigate # what a name means: element, step, trigger, code, helper (bindTemplate, motion)
32
33
  npx @plitzi/cli functions pull # the space's functions (its own server code) into functions/
33
34
  npx @plitzi/cli functions push # functions/ back as the space's draft, built and checked
34
35
  npx @plitzi/cli functions try feed.read --params '{"limit":3}' # one task of the saved draft, in the sandbox
@@ -52,7 +53,6 @@ npx @plitzi/cli functions dev feed.read --watch # the same, fr
52
53
  and social sign-in included — the CLI never sees a password). Tell them a browser tab is waiting, and wait.
53
54
  - **One space at a time.** Everything goes to the space `whoami` names; `plitzi space` switches it. No command takes a
54
55
  space as a flag, so check `whoami --json` (`{ api, user, space }`) before an upload.
55
- - **`--no-install`** writes the files without installing, **`--force`** writes into a directory that has work in it.
56
56
  - **Read stdout, exit code and stderr apart.** The answer is on stdout (`--json`: one object, one line); errors and
57
57
  sign-in prompts are on stderr; exit 1 means it did not do what was asked, or a check found something. A flag value
58
58
  that is not one is refused with what it takes — read the message rather than retrying without the flag.
@@ -65,7 +65,7 @@ Where the space lives decides which one an agent uses — the two never take tur
65
65
  | --- | --- |
66
66
  | In a project, written in code (`src/space.ts`, `--source local`) | this CLI and `@plitzi/sdk-authoring`. No account and no MCP |
67
67
  | On Plitzi — edited in the builder, with collaborators, published from there | the Plitzi MCP server: it reads and edits the live space, previews a page and checks every edit with the same linter |
68
- | On Plitzi, and wanted in code from now on | `create --from <space>`, then `pull` to keep the project in step |
68
+ | On Plitzi, and wanted in code from now on | `create --from <space>`, then `pull` and `push` keep both in step |
69
69
 
70
70
  The MCP needs a signed-in account. If it asks for authentication and nobody can give it, do not wait on it: a project
71
71
  with `--source local` needs neither.
@@ -85,20 +85,21 @@ What a project gives you, so you use it rather than rebuild it:
85
85
  | `start:dev` | server mode: the server, restarted on save |
86
86
  | `author` | author `src/space.ts`: one line when it is fine, every problem at once (file:line, what to change) when not, then the suggestions (`[suggest]`: a shorter way to the same page, the most elements saved first); `-- --json` for a tool |
87
87
  | `npx plitzi fix` | what `author` reports that has one fix, as a diff of your source; `--write` writes it, formatted, and keeps it only if the space then authors with it gone and nothing new |
88
- | `check -- /path --width 1440,390` | whether a page is whole, in text: elements on screen, overflow, console, refused requests, failed flows; `--state` and `--element <id>` say what it holds; `--json` |
89
- | `npx plitzi import <url>` | a page the user owns, measured as a place to start from: `tokens.ts` (colours light and dark, corners, shadows, Google fonts), `outline.ts` (its blocks and their layout per breakpoint), its repeated lists as `data/*.json`, screenshots per width, and `IMPORT.md` saying what was not carried over. Never the words. Only a site whose domain the user verified on one of their spaces (`_plitzi` TXT, under Domains in the dashboard), or one served from this machine — anything else is refused |
90
- | `shot -- /path --width 390 --scheme dark` | a picture of one page — `--clip <element>` one element, `--scroll-to <element>` / `--viewport` the screen there, `--frames 4` what moves, `--compare <url>` how much differs from another site by section; refused if the port is another project's |
88
+ | `check -- /path --width 1440,390` | whether a page is whole, in text: elements on screen, overflow, console, refused requests, failed flows, a binding its data lacks; `--state`, `--element <id>`: what it holds; `--ssr`: what SSR misses; `--json` |
89
+ | `npx plitzi import <url>` | a page the user owns, measured as a place to start from: `tokens.ts` (colours light and dark, corners, shadows, Google fonts), `outline.ts` (its blocks and their layout per breakpoint), its repeated lists as `data/*.json`, screenshots per width, and `IMPORT.md` saying what was not carried over. Never the words. Only a site whose domain the user verified on a space (`_plitzi` TXT, Domains in the dashboard) or served from this machine |
90
+ | `shot -- /path --width 390 --scheme dark` | a picture of one page — `--clip <element>` one element, `--scroll-to <element>` / `--viewport` the screen there, `--frames 4` what moves, `--compare <url>` what differs from another site, by section and by text |
91
91
  | `visual` | a browser asserts every element the space names is visible |
92
92
  | `typecheck`, `lint`, `format` | before calling a change done |
93
93
 
94
- **Which port.** `start` takes 8080, or the next free one when something else holds it — printed, and written to
95
- `.plitzi/dev-server.json`, where `check`, `shot` and `visual` look for it. Set `PORT` to choose one (then a taken port is an
96
- error). `/health` answers with the space's name: a server that answers as something else is not this project.
94
+ **Which port.** `start` takes 8080, or the next free one — printed, and written to `tmp/dev-server.json` for `check`,
95
+ `shot` and `visual`. `PORT` chooses one (a taken one is then an error). `/health` answers with the space's name.
97
96
 
98
97
  The data a page reads with no backend goes in `public/data/*.json`, served by the project as it is; in server mode a
99
98
  provider with `runtime: 'server'` reads it on the server, so the page arrives with it. To bind to a file, learn its fields
100
99
  with `data describe` rather than reading it: a catalogue is half a megabyte, its shape twenty lines.
101
100
 
101
+ **`public/` is on the internet** — never a secret there. `tmp/` (ignored) and `.plitzi/` (committed): `AGENTS.md`.
102
+
102
103
  A local space starts as a tour of the platform with a plugin of the project's own; **`--template blank`** starts it as
103
104
  tokens, a layout and one empty page instead — the one to pick when the project is about to be a specific site; and
104
105
  **`--template catalog`** as a complete small shop (layout, card component, data in `public/data`, a filtered list, a
@@ -189,10 +190,10 @@ The same server decides its own say over the space's **feature flags**: `createS
189
190
  flags the space declares — and is overridden by the SDK's `flags` prop and a tester's dev tools. Declaring the flags
190
191
  themselves is the space's (`flags` in the spec; see the authoring skill's feature flags).
191
192
 
192
- ## A space's functions (`functions`)
193
+ ## Server code (`functions`, `runtime`)
193
194
 
194
- A space's own server code, edited in `functions/` with `pull`, `push`, `try` and `dev`: read
195
- [reference/functions.md](reference/functions.md) when the task names its functions.
195
+ A space's own server code, edited in `functions/` (`pull`, `push`, `try`, `dev`) or run as its runtime
196
+ (`src/runtime.ts`, `runtime push`): read [reference/functions.md](reference/functions.md) for either.
196
197
 
197
198
 
198
199
  ## When something does not work
@@ -201,7 +202,7 @@ A space's own server code, edited in `functions/` with `pull`, `push`, `try` and
201
202
  | --- | --- |
202
203
  | `create` printed questions and wrote nothing | nobody answered the three choices — ask the user, pass them as flags |
203
204
  | `start` says the port is in use | `PORT` is set to a taken port — unset it to take the next free one, or choose another |
204
- | A page that is not this project's, or `shot` refuses the port | another server answers there — `curl 127.0.0.1:<port>/health` names it; `.plitzi/dev-server.json` has this project's port |
205
+ | A page that is not this project's, or `shot` refuses the port | another server answers there — `curl 127.0.0.1:<port>/health` names it; `tmp/dev-server.json` has this project's port |
205
206
  | An element renders "Custom Component … Not Found" | the `renderType` names no registered plugin — check the folder name's camelCase |
206
207
  | A flow on the plugin's event is refused, or never runs | the event is not in `declaration.ts`, or the plugin is missing from `src/plugins/declarations.ts` |
207
208
  | `upload` opens a browser | there is no session, or no space chosen — the person completes it there |
@@ -1,4 +1,4 @@
1
- # A space on Plitzi, as a project (`create --from`, `pull`)
1
+ # A space on Plitzi, as a project (`create --from`, `pull`, `push`)
2
2
 
3
3
  `create --from <space>` (its permanent URL or id) writes a server project holding everything the space is made of, and
4
4
  serving it with nothing of Plitzi's — neither its servers nor its CDN:
@@ -21,3 +21,12 @@ and when one file changed on both it writes **nothing** and names them — keep
21
21
  `--force` to take the space's copy. It never touches `.env`, and only adds to `package.json`. What the project was given
22
22
  is recorded in `.plitzi/space.json`: commit it. It follows the version the project was made from; `pull --environment
23
23
  … --revision …` moves it to another, `--revision latest` lets go of a pin.
24
+
25
+ `push` is the way back: what changed in the project, as the space's **draft** — publishing stays the builder's. At a
26
+ terminal it lists the parts with what changed ticked; otherwise it sends what changed, or the parts named:
27
+ `push space functions` (`space`, `functions`, `runtime`, `plugins`). Plugins go up first, then the functions, the
28
+ runtime, and the pages, actions and connectors last. It is refused when the draft was edited in the builder since the
29
+ project last had it — pull first, or `--force` to replace it — and a project that never had the space may only take a
30
+ space nobody has worked on without `--force`. It pushes to the space the CLI is connected to, which must be the one
31
+ the project came from, and records what it sent in `.plitzi/space.json`, so `pull` works afterwards — on a project that
32
+ started on its own too.
@@ -1,4 +1,4 @@
1
- # A space's functions (`functions`)
1
+ # A space's server code (`functions`, `runtime`)
2
2
 
3
3
  A space's own server code — TypeScript tasks its actions run as steps, and routes under `/fn/` — lives in the space;
4
4
  `functions/` in a project is a **working copy** of it. The contract (`defineFunctions`, `ctx`) is typed in
@@ -16,3 +16,16 @@ A space's own server code — TypeScript tasks its actions run as steps, and rou
16
16
  - **A run gets 100 ms of CPU and 10 s.** A task that needs more asks with `limits: { cpuMs, wallMs }` (or
17
17
  `defineFunctions({ limits })` for all), up to the plan's ceiling; asking above it is a problem the push reports.
18
18
  - **The live site runs what the space was last published with.** A push changes the draft; publishing is the person's.
19
+
20
+ ## A space's runtime (`runtime`)
21
+
22
+ What a function cannot be — Node packages, a connection held open, state across requests — is the space's **runtime**:
23
+ `src/runtime.ts`, default-exporting `defineRuntime` from `@plitzi/sdk-server/runtime` (its `.d.ts` documents it).
24
+
25
+ - `runtime push` packs it (`--entry` for another file) as the draft's runtime; publishing deploys it. Its source goes
26
+ up with it, so `create --from` brings it back.
27
+ - `runtime status` (`--json`) says how each environment's runs, and its variables' names. `runtime vars set NAME`
28
+ reads the value from stdin (`printf %s "$V" | …`), never echo it in a command line; `vars unset NAME` removes one.
29
+ - `runtime size small|medium|large`, `stop`, `start` — the draft's unless `--environment` names a published one.
30
+ - It needs a plan that includes runtimes and a private bucket on the space's CDN; a refusal says which is missing.
31
+