argsbarg 6.1.8 → 6.1.10
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/CHANGELOG.md +23 -1
- package/README.md +160 -68
- package/docs/README.md +1 -0
- package/docs/cli-program.md +2 -0
- package/docs/decisions.md +81 -25
- package/docs/developing.md +1 -1
- package/docs/distribution-homebrew.md +117 -104
- package/docs/http-server.md +3 -1
- package/docs/logging.md +149 -0
- package/examples/full-example/docs/cli-schema.json +18 -18
- package/examples/full-example/docs/cli.md +18 -18
- package/examples/full-example/docs/http.md +13 -1
- package/examples/full-example/justfile +20 -0
- package/index.d.ts +84 -14
- package/package.json +1 -1
- package/src/builtins/http.ts +1 -1
- package/src/builtins/mcp.ts +1 -1
- package/src/core/types.ts +17 -3
- package/src/docs/http-guide.ts +11 -1
- package/src/docs/save.ts +1 -1
- package/src/headless/tool-call.ts +1 -1
- package/src/hooks/run.ts +7 -2
- package/src/http/server.ts +19 -1
- package/src/index.ts +2 -0
- package/src/log/ecs.test.ts +68 -2
- package/src/log/ecs.ts +109 -14
- package/src/log/emitter.test.ts +95 -0
- package/src/log/emitter.ts +74 -11
- package/src/log/trace.test.ts +60 -0
- package/src/log/trace.ts +62 -0
- package/src/runtime/cli.ts +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -7,6 +7,26 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|
|
7
7
|
|
|
8
8
|
## [Unreleased]
|
|
9
9
|
|
|
10
|
+
## [6.1.10] - 2026-07-29
|
|
11
|
+
|
|
12
|
+
### Changed
|
|
13
|
+
|
|
14
|
+
- Update docs
|
|
15
|
+
|
|
16
|
+
## [6.1.9] - 2026-07-27
|
|
17
|
+
|
|
18
|
+
### Added
|
|
19
|
+
|
|
20
|
+
- **ECS Logging–compatible JSON logs** — default JSON output includes `ecs.version`, nested `labels`, canonical HTTP fields (`http.request.method`, `url.path`, `http.response.status_code`, `event.duration` in nanoseconds), and W3C `trace.id` / `span.id` when `traceparent` is present on HTTP requests.
|
|
21
|
+
- **`program.log.enrich`** — additive hook for custom JSON fields (cannot override ECS baseline keys).
|
|
22
|
+
- **`program.log.serialize`** — optional full-line JSON formatter that bypasses the built-in ECS formatter.
|
|
23
|
+
|
|
24
|
+
### Changed
|
|
25
|
+
|
|
26
|
+
- **HTTP trace propagation** — parses incoming `traceparent`, logs trace/span ids, and echoes an updated `traceparent` on responses.
|
|
27
|
+
- **CLI log-format help** — describes JSON as ECS Logging, not generic ECS.
|
|
28
|
+
- **Docs** — new [logging.md](logging.md) (`program.log`, `enrich`, `serialize`, examples); `http-server.md` links there.
|
|
29
|
+
|
|
10
30
|
## [6.1.8] - 2026-07-27
|
|
11
31
|
|
|
12
32
|
### Changed
|
|
@@ -865,7 +885,9 @@ const cli = { ... } satisfies CliProgram; // or : CliProgram
|
|
|
865
885
|
- Migrate schemas: rename every `children` property to **`commands`**; move positional definitions to **`CliPositional`** objects on `positionals` and strip `positional` / `argMin` / `argMax` from flag definitions under `options` (flags only carry `name`, `description`, `kind`, and optional `shortName`).
|
|
866
886
|
- Imports: use `CliPositional` where needed; replace `CliOptionDef` with `CliOption` or `CliPositional` as appropriate.
|
|
867
887
|
|
|
868
|
-
[Unreleased]: https://github.com/bdombro/bun-argsbarg/compare/v6.1.
|
|
888
|
+
[Unreleased]: https://github.com/bdombro/bun-argsbarg/compare/v6.1.10...HEAD
|
|
889
|
+
[6.1.10]: https://github.com/bdombro/bun-argsbarg/releases/tag/v6.1.10
|
|
890
|
+
[6.1.9]: https://github.com/bdombro/bun-argsbarg/releases/tag/v6.1.9
|
|
869
891
|
[6.1.8]: https://github.com/bdombro/bun-argsbarg/releases/tag/v6.1.8
|
|
870
892
|
[6.1.7]: https://github.com/bdombro/bun-argsbarg/releases/tag/v6.1.7
|
|
871
893
|
[6.1.6]: https://github.com/bdombro/bun-argsbarg/releases/tag/v6.1.6
|
package/README.md
CHANGED
|
@@ -5,32 +5,48 @@ Logo
|
|
|
5
5
|
[npm version](https://www.npmjs.com/package/argsbarg)
|
|
6
6
|
[Bun](https://bun.sh)
|
|
7
7
|
|
|
8
|
-
Build beautiful, well-behaved
|
|
8
|
+
Build beautiful, well-behaved, production-grade CLIs, HTTP REST services, MCP Servers for Bun from a single, unified schema. All with only 2 modest dependencies.
|
|
9
9
|
|
|
10
|
-
Why
|
|
10
|
+
Why ArgsBarg?
|
|
11
11
|
|
|
12
|
-
*Schema-first* —
|
|
12
|
+
*Schema-first & Auto-validated* — Define your entire command structure, options, description, and inputs once. ArgsBarg compiles this into type-safe option accessors, command-line routing, and validation schemas, keeping your code and interfaces perfectly aligned.
|
|
13
13
|
|
|
14
|
-
*
|
|
14
|
+
*Automated Schemagen & Docgen* — Maintain single-source truth by decorating standard TypeScript types (`/** @sg */ interface...`) to automatically compile them into runtime validation schemas (`argsbarg schemagen`). Easily export standard-compliant API documentation, full CLI reference markdown, OpenAPI 3.1 definitions, and agent skill sheets directly from your code (`docs --save` command) using introspection.
|
|
15
15
|
|
|
16
|
-
*
|
|
16
|
+
*Production REST Server* — Instantly expose your commands as HTTP REST endpoints (`POST /v1/some-command`) with built-in Kubernetes-compliant `/health/liveness` and `/health/readiness` probes, ECS structured JSON logging to `stderr`, and auto-generated OpenAPI 3.1 specs with an interactive Swagger UI.
|
|
17
17
|
|
|
18
|
-
*
|
|
18
|
+
*First-Class Homebrew Distribution* — Exposes robust native support for packaging and distributing compiled binaries and shell completions cleanly via a standard tap-from-repo Homebrew model. Includes built-in completion script generators (`completion bash`/`zsh`/`fish`) consumed by Homebrew's standard `generate_completions_from_executable` command out of the box, ensuring friction-free installations and updates for your developers.
|
|
19
|
+
|
|
20
|
+
*High-Performance & Light Footprint* — Optimized specifically for Bun. Executes TypeScript and TSX source files directly with no transpile or bundling steps required, leveraging `Bun.serve` for rapid startup and low memory usage. Ships with only two production dependencies (`@cfworker/json-schema` and `ts-json-schema-generator`).
|
|
19
21
|
|
|
20
|
-
*
|
|
22
|
+
*Beautiful* `-h` *screens* — Scoped help at any routing depth, rendered in rounded UTF-8 boxes with tables, terminal-width wrapping, and color when stdout is a TTY. Errors print in red with contextual help on stderr.
|
|
23
|
+
|
|
24
|
+
*Shell completions* — `completion bash`, `completion zsh`, and `completion fish` built-ins generate scripts consumed by Homebrew during formula `install` (`generate_completions_from_executable`). See [docs/distribution-homebrew.md](docs/distribution-homebrew.md).
|
|
21
25
|
|
|
22
26
|
Also checkout ArgsBarg for [cpp](https://github.com/bdombro/cpp-argsbarg), [nim](https://github.com/bdombro/nim-argsbarg), and [swift](https://github.com/bdombro/swift-argsbarg)!
|
|
23
27
|
|
|
24
28
|
Halps! -->
|
|
25
29
|
help-preview.png
|
|
30
|
+
[help-preview.png](docs/help-preview.png)
|
|
31
|
+
|
|
26
32
|
|
|
27
33
|
Sub-level Halps! -->
|
|
28
34
|
help-l2-preview.png
|
|
35
|
+
[help-l2-preview.png](docs/help-l2-preview.png)
|
|
29
36
|
|
|
30
37
|
Shell completions! -->
|
|
31
38
|
completions-preview.png
|
|
39
|
+
[completions-preview.png](docs/completions-preview.png)
|
|
40
|
+
|
|
41
|
+
Production-grade HTTP Server! -->
|
|
42
|
+
```sh
|
|
43
|
+
$ myapp http
|
|
44
|
+
{"@timestamp":"2026-07-29T10:23:59.094Z","message":"HTTP API listening on http://127.0.0.1:13000",...}
|
|
45
|
+
{"@timestamp":"2026-07-29T10:23:59.194Z","message":"GET /health/liveness","ecs.version":"8.11.0",...}
|
|
46
|
+
{"@timestamp":"2026-07-29T10:23:59.195Z","message":"server stopping","ecs.version":"8.11.0",...}
|
|
47
|
+
```
|
|
32
48
|
|
|
33
|
-
## Usage
|
|
49
|
+
## Basic Usage
|
|
34
50
|
|
|
35
51
|
```typescript
|
|
36
52
|
import { Cli, type CliProgram, CliOptionKind } from "argsbarg";
|
|
@@ -85,83 +101,123 @@ Everything you need for a first-class CLI:
|
|
|
85
101
|
- **Rich help**: rounded UTF-8 boxes, tables, terminal width detection (`process.stdout.columns`), colors when stdout/stderr is a TTY
|
|
86
102
|
- **TypeScript-native**: Typed option accessors (`ctx.typedOpt<T>`) and `async/await` handler support.
|
|
87
103
|
|
|
104
|
+
## Getting Started
|
|
88
105
|
|
|
106
|
+
You can either quickly bootstrap a complete, feature-rich project skeleton using our CLI creator or manually integrate ArgsBarg into an existing codebase.
|
|
89
107
|
|
|
90
|
-
|
|
108
|
+
### Option A: Bootstrap a New Project (Recommended)
|
|
91
109
|
|
|
92
|
-
|
|
110
|
+
ArgsBarg provides an interactive project generator to scaffold a new repository fully equipped with TypeScript, Biome, automated schemagen/docgen, standard testing, and Homebrew integration rules:
|
|
93
111
|
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
- `mcp` — when `mcpServer.enabled` is `true`, run as an MCP stdio server (`myapp mcp`).
|
|
98
|
-
- `http` — when `httpServer.enabled` is `true`, run as an HTTP tool server (`myapp http`).
|
|
99
|
-
- `docs` — print bundled markdown topics, schema JSON, CLI markdown, and generated skill content (`myapp docs cli`, `myapp docs cli-schema`, `myapp docs skill`, …). Enabled by default; opt out with `docs: { enabled: false }`. See [docs/bundled-docs.md](docs/bundled-docs.md).
|
|
100
|
-
- `configure` — manage agent skills, MCP config, and app config (`myapp configure --sync --yes` after Homebrew install). See [docs/configure.md](docs/configure.md).
|
|
112
|
+
```bash
|
|
113
|
+
# Interactive setup (prompts for naming and git configurations)
|
|
114
|
+
bunx argsbarg create my-app
|
|
101
115
|
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
116
|
+
# Non-interactive / Headless setup
|
|
117
|
+
bunx argsbarg create my-app \
|
|
118
|
+
--key my-cli --release-repo org/my-cli --yes
|
|
119
|
+
```
|
|
106
120
|
|
|
107
|
-
|
|
121
|
+
Edit `scripts/create-identity.ts` in the new repository to set your description. The `create` command copies the full-featured template, runs `bun install`, bootstraps a git repository (if standalone), and runs initial validation tests.
|
|
108
122
|
|
|
109
|
-
|
|
123
|
+
#### What the bootstrapped template includes:
|
|
110
124
|
|
|
111
|
-
|
|
125
|
+
| Area | Files / wiring |
|
|
126
|
+
| --------------------- | ---------------------------------------------------------------------------------------- |
|
|
127
|
+
| All built-ins | `completion`, `version`, `configure`, `docs`, `mcp`, `http`, `configure get`/`set` |
|
|
128
|
+
| `@sg` schemagen | `/** @sg */` on types in `src/**/*.ts` → `{TypeName}Schema` in `__generated__/` |
|
|
129
|
+
| `outputSchema` | `src/commands/status/types.ts` → `StatusJsonOutputSchema` from `__generated__/` |
|
|
130
|
+
| Schemagen | `just schemagen` → `argsbarg schemagen` (justfile exports `node_modules/.bin` on `PATH`) |
|
|
131
|
+
| Command layout | `src/commands/<name>/command.ts`; registration in `src/program.ts` |
|
|
132
|
+
| MCP doc topics | `docs.topics` auto-exposed as `<key>://docs/<topic>` resources when docs + MCP enabled |
|
|
133
|
+
| Package import | `from "argsbarg"` (not relative to argsbarg `src/`) |
|
|
134
|
+
| Homebrew distribution | `scripts/formula-shared.ts`, `scripts/dev-formula.ts`, `Formula/`, `justfile` |
|
|
135
|
+
| Dev tooling | Biome (`just format` / `just lint`), TypeScript, colocated tests |
|
|
136
|
+
| Cursor rules | `.cursor/rules/cli-program.mdc`, `.cursor/rules/code.mdc` |
|
|
112
137
|
|
|
113
|
-
|
|
138
|
+
*Tip: Verify an existing tree or template setup with `bunx argsbarg create --check .`*
|
|
114
139
|
|
|
115
|
-
|
|
140
|
+
### Option B: Manual Installation (For Existing Projects)
|
|
116
141
|
|
|
117
|
-
|
|
142
|
+
To manually integrate ArgsBarg into your existing Bun application: `bun add argsbarg`.
|
|
118
143
|
|
|
119
|
-
### Configure CLI
|
|
120
144
|
|
|
121
|
-
|
|
145
|
+
## Built-in Commands
|
|
122
146
|
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
147
|
+
ArgsBarg automatically integrates several core features into your application. These are divided into stable core capabilities and optional experimental integrations:
|
|
148
|
+
|
|
149
|
+
### Core Capabilities (Stable)
|
|
150
|
+
|
|
151
|
+
- `-h` / `--help` — Highly-formatted, terminal-width scoped help at any routing depth.
|
|
152
|
+
- `version` — Print the program's version (e.g., `myapp version`).
|
|
153
|
+
- `http` — Launch the high-performance HTTP REST server (injected when `httpServer.enabled` is `true`).
|
|
154
|
+
- `completion bash` / `zsh` / `fish` — Generate shell completion scripts to stdout for deployment and packaging.
|
|
155
|
+
- `docs` — Print bundled markdown topics, schema JSON, or CLI reference markdown (`myapp docs cli`, `myapp docs cli-schema`, etc.). Enabled by default; see [docs/bundled-docs.md](docs/bundled-docs.md).
|
|
156
|
+
- `configure get` / `set` — Query and update application-level configurations non-interactively (active when `program.appConfig` contains configuration schema entries).
|
|
157
|
+
|
|
158
|
+
### Experimental Integrations (Opt-in)
|
|
130
159
|
|
|
131
|
-
|
|
160
|
+
- `mcp` — Run as a Model Context Protocol stdio-based agent server (injected when `mcpServer.enabled` is `true`). See [docs/mcp.md](docs/mcp.md).
|
|
161
|
+
- `configure` (`--sync` / `--status` / `--remove-all`) — Interactive environment setup and developer agent credentials sync (enabled by default; opt out with `configure: { enabled: false }`). See [docs/configure.md](docs/configure.md).
|
|
132
162
|
|
|
133
|
-
|
|
163
|
+
Do not declare top-level commands named `completion`, `version`, or `docs` as they are reserved by default. If their respective features are enabled, `http`, `mcp`, and `configure` are also reserved.
|
|
134
164
|
|
|
135
|
-
|
|
165
|
+
## HTTP REST Server
|
|
166
|
+
|
|
167
|
+
By opting in with `httpServer: { enabled: true }` on your program root, running your app with the `http` subcommand launches a high-performance HTTP REST server powered natively by `Bun.serve`. This is ideal for sidecars, microservices, and micro-container deployments (such as in Kubernetes).
|
|
168
|
+
|
|
169
|
+
Nested command paths map directly to standard REST paths (e.g., `v1 invoices render` maps to `POST /v1/invoices/render`).
|
|
170
|
+
|
|
171
|
+
```typescript
|
|
172
|
+
const cli = {
|
|
173
|
+
key: "myapp",
|
|
174
|
+
version: "1.0.0",
|
|
175
|
+
description: "My service.",
|
|
176
|
+
httpServer: { enabled: true, port: 3000 },
|
|
177
|
+
commands: [/* ... */],
|
|
178
|
+
} satisfies CliProgram;
|
|
179
|
+
```
|
|
136
180
|
|
|
137
181
|
```bash
|
|
138
|
-
myapp
|
|
139
|
-
myapp completion zsh
|
|
140
|
-
myapp completion fish
|
|
182
|
+
myapp http --port 3000
|
|
141
183
|
```
|
|
142
184
|
|
|
143
|
-
Users configure their shell per [Homebrew Shell Completion](https://docs.brew.sh/Shell-Completion).
|
|
144
185
|
|
|
145
|
-
|
|
186
|
+
|
|
187
|
+
### Key HTTP Features:
|
|
188
|
+
|
|
189
|
+
- **Built-in Health Checks** — Automatic `/health/liveness` (responds 200 when online) and `/health/readiness` (responds 200 when online and config validation passes) probes out of the box, compliant with container orchestrators.
|
|
190
|
+
- **OpenAPI 3.1 Spec & Swagger UI** — Serves standard `/openapi.json` and a `/swagger` interactive API browser generated directly from your command schema and JSDoc metadata.
|
|
191
|
+
- **Pre-Handler Schema Validation** — Incoming request payloads are validated against the compile-time JSON Schema (`inputSchema`) on leaf commands before your handler ever runs.
|
|
192
|
+
- **ECS Structured Logging** — Access and error logs are automatically structured as Elastic Common Schema (ECS) JSON objects and written to `stderr` (e.g., for Datadog or ELK collection).
|
|
193
|
+
- **W3C Distributed Tracing** — Automatically parses, propagates, and echoes `traceparent` headers for distributed tracing pipelines.
|
|
194
|
+
|
|
195
|
+
See **[docs/http-server.md](docs/http-server.md)** for details on endpoints and response shapes, and **[docs/logging.md](docs/logging.md)** for log configurations.
|
|
196
|
+
|
|
197
|
+
## Distribution & Packaging (Homebrew)
|
|
198
|
+
|
|
199
|
+
ArgsBarg is built to distribute the compiled binary and shell completions cleanly through Homebrew via a standard **tap-from-repo** model.
|
|
200
|
+
|
|
201
|
+
### Installation & Post-Install Setup:
|
|
146
202
|
|
|
147
203
|
```bash
|
|
148
|
-
|
|
204
|
+
brew tap <org>/<repo> git@github.com:<org>/<repo>.git
|
|
205
|
+
brew install <tap>/myapp
|
|
149
206
|
```
|
|
150
207
|
|
|
208
|
+
During installation, Homebrew registers the built-in generated shell completions automatically via `generate_completions_from_executable` (see [docs/distribution-homebrew.md](docs/distribution-homebrew.md)).
|
|
151
209
|
|
|
210
|
+
### Shell Completions:
|
|
152
211
|
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
Argsbarg ships authoring docs in `node_modules/argsbarg/docs/`. Agents do not load them unless your repo points there — copy the thin Cursor rule after install (it tells agents to **read** `cli-program.md`, not duplicate it):
|
|
212
|
+
Completion scripts can also be output directly at any time for manual setups or formula auditing:
|
|
156
213
|
|
|
157
214
|
```bash
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
node_modules/argsbarg/examples/full-example/.cursor/rules/cli-program.mdc
|
|
215
|
+
myapp completion bash
|
|
216
|
+
myapp completion zsh
|
|
217
|
+
myapp completion fish
|
|
162
218
|
```
|
|
163
219
|
|
|
164
|
-
|
|
220
|
+
|
|
165
221
|
|
|
166
222
|
## How it works
|
|
167
223
|
|
|
@@ -230,7 +286,7 @@ Check the `examples/` directory for full working scripts:
|
|
|
230
286
|
| --------------------- | ------------------------ | ------------------------------------------------------------------------------------------------- |
|
|
231
287
|
| `ArgsBargMinimal` | `examples/minimal.ts` | String + presence flags, `MissingOrUnknown` fallback. |
|
|
232
288
|
| `ArgsBargNested` | `examples/nested.ts` | Nested command tree, positional tails, async handlers. |
|
|
233
|
-
| `ArgsBargFormats` | `examples/formats.ts` | `CliValueFormat`, `default`, `ctx.inputs`.
|
|
289
|
+
| `ArgsBargFormats` | `examples/formats.ts` | `CliValueFormat`, `default`, `ctx.inputs`. |
|
|
234
290
|
| `ArgsBargFullExample` | `examples/full-example/` | **Copy template:** all builtins, schemagen, Homebrew justfile, `outputSchema`, `from "argsbarg"`. |
|
|
235
291
|
|
|
236
292
|
|
|
@@ -266,21 +322,21 @@ To refresh Cursor rules in an existing consumer: `bun scripts/merge-cli-program-
|
|
|
266
322
|
### What the full-example template includes
|
|
267
323
|
|
|
268
324
|
|
|
269
|
-
| Area | Files / wiring
|
|
270
|
-
| --------------------- |
|
|
271
|
-
| All builtins | `completion`, `version`, `configure`, `docs`, `mcp`, `http`, `configure get`/`set`
|
|
272
|
-
| `@sg` schemagen | `/** @sg */` on types in `src/**/*.ts` → `{TypeName}Schema` in `__generated__/`
|
|
273
|
-
| `outputSchema` | `src/commands/status/types.ts` → `StatusJsonOutputSchema` from `__generated__/`
|
|
325
|
+
| Area | Files / wiring |
|
|
326
|
+
| --------------------- | ---------------------------------------------------------------------------------------- |
|
|
327
|
+
| All builtins | `completion`, `version`, `configure`, `docs`, `mcp`, `http`, `configure get`/`set` |
|
|
328
|
+
| `@sg` schemagen | `/** @sg */` on types in `src/**/*.ts` → `{TypeName}Schema` in `__generated__/` |
|
|
329
|
+
| `outputSchema` | `src/commands/status/types.ts` → `StatusJsonOutputSchema` from `__generated__/` |
|
|
274
330
|
| Schemagen | `just schemagen` → `argsbarg schemagen` (justfile exports `node_modules/.bin` on `PATH`) |
|
|
275
|
-
| Command layout | `src/commands/<name>/command.ts`; registration in `src/program.ts`
|
|
276
|
-
| MCP doc topics | `docs.topics` auto-exposed as `<key>://docs/<topic>` resources when docs + MCP enabled
|
|
277
|
-
| Package import | `from "argsbarg"` (not relative to argsbarg `src/`)
|
|
278
|
-
| Homebrew distribution | `scripts/formula-shared.ts`, `scripts/dev-formula.ts`, `Formula/`, `justfile`
|
|
279
|
-
| Dev tooling | Biome (`just format` / `just lint`), TypeScript, colocated tests
|
|
280
|
-
| Cursor rules | `.cursor/rules/cli-program.mdc`, `.cursor/rules/code.mdc`
|
|
331
|
+
| Command layout | `src/commands/<name>/command.ts`; registration in `src/program.ts` |
|
|
332
|
+
| MCP doc topics | `docs.topics` auto-exposed as `<key>://docs/<topic>` resources when docs + MCP enabled |
|
|
333
|
+
| Package import | `from "argsbarg"` (not relative to argsbarg `src/`) |
|
|
334
|
+
| Homebrew distribution | `scripts/formula-shared.ts`, `scripts/dev-formula.ts`, `Formula/`, `justfile` |
|
|
335
|
+
| Dev tooling | Biome (`just format` / `just lint`), TypeScript, colocated tests |
|
|
336
|
+
| Cursor rules | `.cursor/rules/cli-program.mdc`, `.cursor/rules/code.mdc` |
|
|
281
337
|
|
|
282
338
|
|
|
283
|
-
When changing builtins or the template, run `just
|
|
339
|
+
When changing builtins or the template, run `just example-full-check` from the argsbarg repo root.
|
|
284
340
|
|
|
285
341
|
```bash
|
|
286
342
|
export PATH="$PATH:$(pwd)/examples"
|
|
@@ -301,6 +357,42 @@ just run status --json
|
|
|
301
357
|
|
|
302
358
|
|
|
303
359
|
|
|
360
|
+
## [Experimental] AI Agent & Copilot Integrations
|
|
361
|
+
|
|
362
|
+
ArgsBarg includes optional experimental features designed to make your CLI and services easily discoverable and executable by modern developer AI agents (such as Cursor, Claude Code, and standard MCP clients). These are entirely opt-in and do not affect the footprint, performance, or stability of the core CLI and HTTP layers.
|
|
363
|
+
|
|
364
|
+
### 1. Model Context Protocol (MCP) Server
|
|
365
|
+
|
|
366
|
+
Opt in by setting `mcpServer: { enabled: true }` on your program root. Running `myapp mcp` starts a JSON-RPC 2.0 stdio server.
|
|
367
|
+
|
|
368
|
+
- **Automatic Tool Exposure** — Every leaf command in your CLI tree becomes an executable MCP tool with inputs automatically generated from your CLI options.
|
|
369
|
+
- **Documentation Resources** — Your CLI structure, JSON schemas, and bundled `docs.topics` are automatically exposed to agents as resources (e.g., `<key>://schema`).
|
|
370
|
+
- **Context-Aware Invocations** — Handlers can read `ctx.invocation` to distinguish between direct CLI, HTTP requests, or headless MCP calls.
|
|
371
|
+
|
|
372
|
+
See **[docs/mcp.md](docs/mcp.md)** for configuration, env bootstrapping, custom resources, Cursor/Claude setup, and protocol details.
|
|
373
|
+
|
|
374
|
+
### 2. IDE Copilot Rules (Cursor / Claude Code)
|
|
375
|
+
|
|
376
|
+
ArgsBarg ships authoring docs under `node_modules/argsbarg/docs/`. Because AI agents do not automatically read inside `node_modules/`, you can copy a thin custom rule into your project:
|
|
377
|
+
|
|
378
|
+
```bash
|
|
379
|
+
mkdir -p .cursor/rules
|
|
380
|
+
bun scripts/merge-cli-program-rule.ts . \
|
|
381
|
+
node_modules/argsbarg/examples/full-example/.cursor/rules/cli-program.mdc
|
|
382
|
+
```
|
|
383
|
+
|
|
384
|
+
This acts as a "tripwire" that instructs AI agents in your workspace to read ArgsBarg's framework documentation before modifying your command definitions or schemas. See the **Cursor rule** section in [docs/cli-program.md](docs/cli-program.md).
|
|
385
|
+
|
|
386
|
+
### 3. Generated Skills & Workspace Configuration
|
|
387
|
+
|
|
388
|
+
Running `myapp configure` launches an interactive setup wizard that can automatically write compact `SKILL.md` index files and full-reference markdown files (`reference.md`) directly into your global IDE directories (e.g., `~/.cursor/skills/` or `~/.claude/skills/`).
|
|
389
|
+
|
|
390
|
+
See **[docs/configure.md](docs/configure.md)** and **[docs/ai-skills.md](docs/ai-skills.md)** for developer setup and automated Homebrew pipeline integration.
|
|
391
|
+
|
|
392
|
+
---
|
|
393
|
+
|
|
394
|
+
|
|
395
|
+
|
|
304
396
|
## Public API overview
|
|
305
397
|
|
|
306
398
|
The package root (`argsbarg` / `src/index.ts`) exports the types and runtime you need to define a schema and run it. Parsing, completion script generation, help rendering, and schema pre-validation live in other modules under `src/` for tests and advanced integrations.
|
|
@@ -311,8 +403,8 @@ The package root (`argsbarg` / `src/index.ts`) exports the types and runtime you
|
|
|
311
403
|
| `CliProgram`, `CliOption`, `CliPositional`, `CliHandler` | Schema and handler types. |
|
|
312
404
|
| `CliOptionKind`, `CliValueFormat`, `CliFallbackMode` | Option kinds, value formats (`duration`, `comma-list`, `date`, `date-time`), and root fallback behavior. |
|
|
313
405
|
| `CliSchemaValidationError` | Thrown when the static command tree violates schema rules. |
|
|
314
|
-
| `CliContext` | Handler context (`ctx.hasFlag`, `ctx.stringOpt`, `ctx.durationOpt`, `ctx.inputs`, `ctx.invocation`, …).
|
|
315
|
-
| `CliLeafInputs` | Record type returned by `ctx.inputs` — coerced option/positional values keyed by schema name.
|
|
406
|
+
| `CliContext` | Handler context (`ctx.hasFlag`, `ctx.stringOpt`, `ctx.durationOpt`, `ctx.inputs`, `ctx.invocation`, …). |
|
|
407
|
+
| `CliLeafInputs` | Record type returned by `ctx.inputs` — coerced option/positional values keyed by schema name. |
|
|
316
408
|
| `Cli` | Runtime: validate + freeze program, `run()`, `invoke()`, `serveMcp()`, `appConfig` getter, `exportCommandSchema()`, `exportAppConfigSchema()`. |
|
|
317
409
|
| `CliInvokeResult`, `CliInvokeKind` | Result types from `cli.invoke()`. |
|
|
318
410
|
| `CliAppConfig`, `CliAppConfigEntry` | App config block on the program root (`entries` metadata overlay + optional `jsonSchema`). |
|
package/docs/README.md
CHANGED
|
@@ -11,6 +11,7 @@ Start here to pick the right guide.
|
|
|
11
11
|
| **JSON Schema validation** | [json-schema-subset.md](json-schema-subset.md) — Draft-07 / 2019-09 / 2020-12 (`$schema` on each schema; default Draft-07) |
|
|
12
12
|
| **Exposing MCP tools** | [mcp.md](mcp.md) — stdio server, `inputSchema`, varargs, `configure --sync` |
|
|
13
13
|
| **HTTP tool server** | [http-server.md](http-server.md) — `myapp http`, endpoints, curl examples |
|
|
14
|
+
| **Server logging** (`program.log`, `enrich`, `serialize`) | [logging.md](logging.md) — ECS JSON lines, trace headers, custom formats |
|
|
14
15
|
| **Shipping configure / agent artifacts** | [configure.md](configure.md) — Homebrew + `myapp configure --sync` |
|
|
15
16
|
| **Homebrew tap-from-repo distribution** | [distribution-homebrew.md](distribution-homebrew.md) — formula pattern, `argsbarg create` |
|
|
16
17
|
| **Bundling `myapp docs` topics** | [bundled-docs.md](bundled-docs.md) — consumer docgen vs framework docs |
|
package/docs/cli-program.md
CHANGED
|
@@ -41,6 +41,8 @@ const cli = {
|
|
|
41
41
|
|
|
42
42
|
`httpServer` and `mcpServer` are independent. Tool exposure uses the same rules (`mcpTool.enabled: false` hides from MCP and HTTP). See [http-server.md](http-server.md).
|
|
43
43
|
|
|
44
|
+
**Logging** — HTTP and MCP server logs go to stderr (JSON by default). Configure `program.log` on the program root; use **`enrich`** to add fields or **`serialize`** for a fully custom line. See **[logging.md](logging.md)**.
|
|
45
|
+
|
|
44
46
|
## Inline schema by default
|
|
45
47
|
|
|
46
48
|
ArgsBarg is **schema-first** — the program tree is the product. **Keep `CliProgram` and leaf fields inline** (`key`, `description`, `options`, `positionals`, `handler`) so a reader sees the full command contract in one place.
|
package/docs/decisions.md
CHANGED
|
@@ -1,40 +1,96 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Architecture Decision Records (ADRs)
|
|
2
2
|
|
|
3
|
-
This
|
|
3
|
+
This document records the key architectural decisions made during the design and implementation of ArgsBarg.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
---
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
## ADR 1: Exclusively Support Bun as the JavaScript/TypeScript Runtime
|
|
8
|
+
|
|
9
|
+
### Status
|
|
10
|
+
|
|
11
|
+
Accepted
|
|
8
12
|
|
|
9
13
|
### Context
|
|
10
14
|
|
|
11
|
-
|
|
12
|
-
|
|
15
|
+
We evaluated whether to build ArgsBarg as a dual-runtime library supporting both Node.js and Bun, or to target Bun exclusively.
|
|
16
|
+
|
|
17
|
+
Supporting Node.js requires maintaining complex build steps (transpilation, bundlers, CommonJS vs ESM dual-packaging, polyfills for HTTP serving) and limits the features we can offer to both the library and its consumers.
|
|
18
|
+
|
|
19
|
+
### Decision
|
|
20
|
+
|
|
21
|
+
Exclusively support Bun as the sole runtime for ArgsBarg and its consumer applications.
|
|
22
|
+
|
|
23
|
+
### Consequences
|
|
24
|
+
|
|
25
|
+
- **Pros:**
|
|
26
|
+
- **Zero-Build, Source-First Architecture:** Because Bun executes TypeScript and TSX directly from source, consumers can run their source code directly in production without any transpile or bundling steps (no Babel, Webpack, `ts-node`, or `tsx` required).
|
|
27
|
+
- **High-Performance Native HTTP (**`Bun.serve`**):** ArgsBarg's HTTP REST server is built directly on top of Bun's native, ultra-fast HTTP stack, offering millisecond-range startup times and massive throughput out of the box with zero boilerplate.
|
|
28
|
+
- **Native File and Text Imports:** ArgsBarg leverages Bun's native import attributes (e.g., `import readmeText from "./README.md" with { type: "text" }`) to bundle documentation and schemas at compile-time without reading the filesystem at runtime or requiring custom bundler plugins.
|
|
29
|
+
- **Unified, Lightweight Toolchain:** Both the framework and consumers benefit from Bun's native, ultra-fast package manager, built-in test runner (`bun test`), and zero-config TypeScript support, keeping the project's footprint and developer friction incredibly low.
|
|
30
|
+
- **Cons (What We Lose):**
|
|
31
|
+
- **Loss of Node-Only Enterprise Tooling:** We lose out-of-the-box integration with legacy enterprise APMs (Application Performance Monitoring like Datadog, New Relic) and security/compliance scanners that are strictly compiled for Node.js runtimes or depend on Node's internal V8 debugging APIs.
|
|
32
|
+
- **Serverless Platform Friction:** Standard serverless platforms (e.g., AWS Lambda, Google Cloud Functions) have optimized native runtimes for Node.js, whereas running Bun on these platforms requires deploying custom layers or heavier Docker containers.
|
|
33
|
+
- **Reduced Addressable Library Adoption:** By locking out standard Node.js environments, we lose a significant portion of the mainstream Node.js developer base who cannot adopt Bun due to rigid corporate policies, legacy infrastructure, or strict compliance guidelines.
|
|
34
|
+
- **100% Node API Compatibility Guarantee:** While Bun's Node compatibility layer is exceptionally high, we lose the 100% absolute guarantee that legacy CommonJS packages or complex native C++ addons (N-API) will run flawlessly without minor polyfill adjustments.
|
|
35
|
+
- **No Node.js Execution Path:** Applications cannot run on standard Node.js without a separate bundling/transpilation layer, making ArgsBarg a Bun-exclusive framework.
|
|
36
|
+
|
|
37
|
+
---
|
|
13
38
|
|
|
14
|
-
### Rationale
|
|
15
39
|
|
|
16
|
-
1. Command tree already encodes hierarchy — REST paths mirror `http.segment ?? key` plus `:param` routers
|
|
17
|
-
2. Verb leaves (`get`, `post`, …) map to HTTP methods without duplicating path segments
|
|
18
|
-
3. OpenAPI paths match real URLs clients call; query/body binding matches MCP flat args
|
|
19
|
-
4. Hard break on `/tools/*` is acceptable pre-7.0-ship
|
|
20
40
|
|
|
21
|
-
##
|
|
41
|
+
## ADR 2: Schema-Driven Contracts via JSON Schema (vs Zod)
|
|
22
42
|
|
|
23
|
-
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
### Status
|
|
46
|
+
|
|
47
|
+
Accepted
|
|
24
48
|
|
|
25
49
|
### Context
|
|
26
|
-
- JSON-SCHEMA is an open standard to capture a schema in json
|
|
27
|
-
- Zod is the leading Typescript schema management library
|
|
28
|
-
- Others are similar or less good than Zod
|
|
29
50
|
|
|
30
|
-
|
|
31
|
-
|
|
51
|
+
We evaluated schema management and runtime validation libraries—specifically comparing the TypeScript-first library **Zod** against the industry-standard **JSON Schema** specification—for input and configuration contracts.
|
|
52
|
+
|
|
53
|
+
### Decision
|
|
54
|
+
|
|
55
|
+
Adopt JSON Schema (using `@cfworker/json-schema` and `ts-json-schema-generator`) as the core validation format.
|
|
56
|
+
|
|
57
|
+
### Consequences
|
|
58
|
+
|
|
59
|
+
- **Pros:**
|
|
60
|
+
- **Dynamic Manipulation:** Allows ArgsBarg to dynamically slice, patch, and transform schemas at runtime for different targets (CLI parser, MCP tools, OpenAPI JSON, and app configuration). This is far more complex to do with Zod.
|
|
61
|
+
- **Tooling Parity:** Integrates cleanly with a "write TypeScript, compile to schema" developer workflow.
|
|
62
|
+
- **Better IntelliSense:** Users write plain TypeScript interface definitions rather than chained Zod schemas, resulting in cleaner code and zero-abstraction IntelliSense.
|
|
63
|
+
- **Interop:** Consumers who prefer Zod can still use it and convert their schemas via `zod-to-json-schema` before passing them to ArgsBarg.
|
|
64
|
+
- **Cons:**
|
|
65
|
+
- Fewer expressive, runtime-only custom validation features (like refinements and transformations) built into the framework core.
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
|
|
70
|
+
|
|
71
|
+
## ADR 3: Structured Logging (ECS-Compatible JSON)
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+
### Status
|
|
76
|
+
|
|
77
|
+
Accepted (v6.1.9)
|
|
78
|
+
|
|
79
|
+
### Context
|
|
80
|
+
|
|
81
|
+
HTTP and MCP servers require standard, trace-correlated, and easily digestible access and error logging for production pipelines (such as Datadog, Elasticsearch, and GCP logs). We wanted to deliver first-class, standard-compliant logs out of the box without introducing heavy third-party observability libraries or proprietary schemas.
|
|
82
|
+
|
|
83
|
+
### Decision
|
|
84
|
+
|
|
85
|
+
Emit server access and error logs to `stderr` formatted as Elastic Common Schema (ECS)-compatible NDJSON by default, with optional `program.log.enrich` and `program.log.serialize` hooks.
|
|
86
|
+
|
|
87
|
+
### Consequences
|
|
32
88
|
|
|
33
|
-
|
|
89
|
+
- **Pros:**
|
|
90
|
+
- **Industry Standard:** ECS-compatible fields (`ecs.version`, `log.level`, etc.) play perfectly with all standard log collectors (ELK, Fluent Bit, Datadog).
|
|
91
|
+
- **Twelve-Factor Native:** Writing structured JSON to `stderr` keeps `stdout` clean for CLI command payloads and output redirects.
|
|
92
|
+
- **Distributed Tracing:** Standard W3C `traceparent` headers are automatically parsed and propagated without proprietary metadata layouts.
|
|
93
|
+
- **Zero Heavy Dependencies:** Avoids bundling heavy OpenTelemetry SDKs or other binary telemetry clients in the core open-source library.
|
|
94
|
+
- **Cons:**
|
|
95
|
+
- Requires minor log collector or format mapper adjustments if the deployment environment is strictly standardized on a non-ECS log layout.
|
|
34
96
|
|
|
35
|
-
1. Argsbarg does a lot of schema patching/manipulation to create different schemas per target (cli-schema.json, MCP contract, openapi.json). This would be harder with Zod
|
|
36
|
-
2. Consumers can use Zod by converting to JSON Schema (`zod-to-json-schema`, `z.toJSONSchema()`) and passing the result to `inputSchema` / `appConfig.jsonSchema`. Argsbarg resolves the validator draft from each schema’s `$schema` (Draft-07 default; 2019-09 / 2020-12 when set).
|
|
37
|
-
3. For uses like API pass-through, proxy, dynamic schemas, Zod may actually explode complexity for consumers.
|
|
38
|
-
4. Our TS->json-schema approach is actually easier and better in many cases
|
|
39
|
-
- Just write plain typescript, done.
|
|
40
|
-
- Better intellisense -- substantially less abstraction/inference, much better control
|
package/docs/developing.md
CHANGED
|
@@ -70,7 +70,7 @@ Exclude `examples/full-example/node_modules/` from the npm tarball via [`.npmign
|
|
|
70
70
|
[`examples/full-example/`](../examples/full-example/) must enable every builtin (`capabilities.test.ts`). After builtin or schemagen doc changes:
|
|
71
71
|
|
|
72
72
|
```bash
|
|
73
|
-
just full-
|
|
73
|
+
just example-full-schemagen
|
|
74
74
|
just test
|
|
75
75
|
```
|
|
76
76
|
|