@azx-pbc/helix-cli 0.2.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/README.md +31 -6
- package/dist/helix.js +943 -429
- package/package.json +5 -4
package/README.md
CHANGED
|
@@ -28,12 +28,24 @@ Each setting is resolved **flags → environment → `helix.json` → built-in d
|
|
|
28
28
|
| Build dir | `--dir` | — | `dir` | `dist` |
|
|
29
29
|
| Auth token | `--token` | `HELIX_TOKEN` | — | _(`helix login` if unset)_ |
|
|
30
30
|
|
|
31
|
-
A
|
|
31
|
+
A `helix.json` looks like:
|
|
32
32
|
|
|
33
33
|
```json
|
|
34
|
-
{ "slug": "my-app" }
|
|
34
|
+
{ "slug": "my-app", "dir": "dist", "portalUrl": "https://portal.example.com" }
|
|
35
35
|
```
|
|
36
36
|
|
|
37
|
+
**`portalUrl` is the one you cannot leave to the default.** `http://localhost:3001`
|
|
38
|
+
is right only for a portal running on your own machine; against a deployed one,
|
|
39
|
+
set `portalUrl` (or `HELIX_PORTAL_URL`, or `--portal-url`) or every command —
|
|
40
|
+
starting with `helix login` — fails to connect to a portal that was never there.
|
|
41
|
+
Your portal prints the exact file to copy under **How to develop → On your
|
|
42
|
+
machine**. The file is the form worth checking in: `login`, `create`, `deploy`
|
|
43
|
+
and `promote` all resolve it the same way, so it is set once.
|
|
44
|
+
|
|
45
|
+
The repo's `examples/*/helix.json` deliberately omit it — a checked-in portal URL
|
|
46
|
+
would be wrong for every deployment but one — so to deploy an example, add
|
|
47
|
+
`portalUrl` to its file or export `HELIX_PORTAL_URL` first.
|
|
48
|
+
|
|
37
49
|
`--dir` is resolved **relative to the current working directory**, and so is
|
|
38
50
|
`helix.json` — another reason to run `helix` from the app directory.
|
|
39
51
|
|
|
@@ -48,12 +60,20 @@ helix deploy [--dir <dir>] [--bundle <zip>] [--promote] # upload a version
|
|
|
48
60
|
helix versions # list versions
|
|
49
61
|
helix promote <number> # make a version live
|
|
50
62
|
helix rollback [number] # revert the live pointer
|
|
63
|
+
helix skill [--path <file>] # write this deployment's agent skill to disk
|
|
51
64
|
```
|
|
52
65
|
|
|
53
66
|
`deploy` uploads the bundle as a **preview**; `--promote` flips it live in the
|
|
54
|
-
same step (architecture §5.1). `visibility` is `internal | group:<id> | password
|
|
67
|
+
same step (architecture §5.1). `visibility` is `internal | group:<id>[,<id>…] | password
|
|
55
68
|
| public`.
|
|
56
69
|
|
|
70
|
+
`helix skill` fetches this deployment's rendered agent skill (`GET /api/v1/skill`,
|
|
71
|
+
ADR-0036) — the same document the portal's **How to develop** modal hands out, with
|
|
72
|
+
this deployment's hosts, servable models, and approval baselines already substituted
|
|
73
|
+
in. It needs no app slug or `helix.json`, only a portal URL and a token. Defaults to
|
|
74
|
+
`./SKILL.md`; `--path .claude/skills/helix/SKILL.md` drops it where a Claude Code
|
|
75
|
+
agent reads it off disk.
|
|
76
|
+
|
|
57
77
|
> **Breaking in 0.2.0:** the `private` visibility mode was renamed to `internal`.
|
|
58
78
|
> It never checked _which_ user signed in, only that someone had. Passing the old
|
|
59
79
|
> value now **errors** rather than mapping to the new one, deliberately: the name
|
|
@@ -87,12 +107,17 @@ export HELIX_TOKEN="…"
|
|
|
87
107
|
helix deploy --promote
|
|
88
108
|
```
|
|
89
109
|
|
|
90
|
-
Needs **Node
|
|
91
|
-
|
|
110
|
+
Needs **Node 22.12+** (or 24+). The engines range and the bundle's esbuild
|
|
111
|
+
target move together (see `scripts/build.mjs`), so the declared floor is real:
|
|
112
|
+
older runtimes may not merely warn, they may fail to parse it.
|
|
92
113
|
|
|
93
114
|
`0.0.0` is a deprecated placeholder that exists only because npm requires a
|
|
94
115
|
package to exist before a trusted publisher can be attached to it. Every real
|
|
95
|
-
version is `0.1.0` or later and carries a provenance attestation.
|
|
116
|
+
version is `0.1.0` or later and carries a provenance attestation. npm filters
|
|
117
|
+
registry versions by `engines` against the running runtime, so before 0.3.0
|
|
118
|
+
declared 22.12+ an install on Node 22 fell all the way back to that
|
|
119
|
+
placeholder — the reason a supported-looking Node could yield a
|
|
120
|
+
non-functional package.
|
|
96
121
|
|
|
97
122
|
### From this monorepo today
|
|
98
123
|
|