docs: generated README

This commit is contained in:
morten-olsen
2025-05-19 07:15:52 +00:00
committed by github-actions[bot]
parent ab2bb38f39
commit bf14ef97b8

432
README.md
View File

@@ -2,35 +2,71 @@
**`http.md` is a powerful tool that transforms your markdown files into living, executable API documentation and testing suites. Write your HTTP requests directly within markdown, see their responses, and use templating to build dynamic examples and test flows.**
It allows developers to create API documentation that is always accurate and up-to-date because the documentation itself _is_ the set of executable requests. This ensures that your examples work and your tests run directly from the documents you share.
It allows developers to create API documentation that is always accurate and up-to-date because the documentation itself *is* the set of executable requests. This ensures that your examples work and your tests run directly from the documents you share.
## Key Features
- **Markdown-Native:** Define HTTP requests using familiar markdown code blocks.
- **Live Requests:** Execute requests and embed their responses directly into your documentation.
- **Templating:** Use Handlebars syntax to chain requests, extract data from responses, and use external inputs.
- **File Embedding:** Include and reuse requests from other markdown files.
- **Terminal & File Output:** View live previews in your terminal or build static markdown files for sharing or static site generation.
- **Watch Mode:** Automatically re-render documents on file changes for a fast development loop.
- **Flexible Configuration:** Control request execution, output formatting, and visibility.
* **Markdown-Native:** Define HTTP requests using familiar markdown code blocks.
* **Live Requests:** Execute requests and embed their responses directly into your documentation.
* **Templating:** Use Handlebars syntax to chain requests, extract data from responses, and use external inputs.
* **File Embedding:** Include and reuse requests from other markdown files.
* **Terminal & File Output:** View live previews in your terminal or build static markdown files for sharing or static site generation.
* **Watch Mode:** Automatically re-render documents on file changes for a fast development loop.
* **Flexible Configuration:** Control request execution, output formatting, and visibility.
## Use Cases
- **API Documentation:** Create clear, executable examples that users can trust.
- **Integration Testing:** Write simple integration test suites that verify API behavior.
- **Tutorials & Guides:** Build step-by-step guides where each HTTP interaction is shown with its real output.
- **Rapid Prototyping:** Quickly experiment with APIs and document your findings.
* **API Documentation:** Create clear, executable examples that users can trust.
* **Integration Testing:** Write simple integration test suites that verify API behavior.
* **Tutorials & Guides:** Build step-by-step guides where each HTTP interaction is shown with its real output.
* **Rapid Prototyping:** Quickly experiment with APIs and document your findings.
## Roadmap
* **Programmatic API** Use `http.md` inside existing scripts and pipelines
* **Environment Varaiables** Support using the runners environment variables in templates
* **JavaScript script support** Add JavaScript code blocks with execution, which will allow more advanced use-cases
* **Asserts** Add the ability to make HTTP assertions to use the document for testing
* **Templates** Write re-usable templates which can be used in documents
## Content
* [Key Features](#key-features)
* [Use Cases](#use-cases)
* [Roadmap](#roadmap)
* [Content](#content)
* [Installation](#installation)
* [Getting Started](#getting-started)
* [Your First Request](#your-first-request)
* [Rendering Documents](#rendering-documents)
* [Core Concepts](#core-concepts)
* [HTTP Request Blocks](#http-request-blocks)
* [The `::response` Directive](#the-response-directive)
* [Request IDs](#request-ids)
* [Templating with Handlebars](#templating-with-handlebars)
* [Available Variables for Templating](#available-variables-for-templating)
* [Templating Examples](#templating-examples)
* [Managing Documents](#managing-documents)
* [Embedding Other Documents (`::md`)](#embedding-other-documents-md)
* [Advanced Usage](#advanced-usage)
* [Using Input Variables](#using-input-variables)
* [HTTP Block Configuration Options](#http-block-configuration-options)
* [Directive Options](#directive-options)
* [`::response` Directive Options](#response-directive-options)
* [`::md[{file}]` Directive Options](#mdfile-directive-options)
* [`::input[{name}]` Directive Options](#inputname-directive-options)
* [Command-Line Interface (CLI)](#command-line-interface-cli)
* [`http.md dev <source_file.md>`](#httpmd-dev-source_filemd)
* [`http.md build <source_file.md> <output_file.md>`](#httpmd-build-source_filemd-output_filemd)
## Installation
Install `http.md` globally using npm:
```shell
npm i -g http.md
npm i -g @morten-olsen/http.md
```
Or use `npx http.md` instead of `http.md`
## Getting Started
### Your First Request
@@ -54,6 +90,7 @@ Content-Type: application/json
And here is the response:
::response
````
### Rendering Documents
@@ -106,43 +143,44 @@ Content-Type: application/json
And here is the response:
```
```http
HTTP/200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
connection: keep-alive
content-length: 555
content-length: 559
content-type: application/json
date: Sun, 18 May 2025 19:12:17 GMT
date: Mon, 19 May 2025 07:15:17 GMT
server: gunicorn/19.9.0
{
"args": {},
"data": "{\"greeting\": \"Hello, http.md!\"}",
"files": {},
"form": {},
"args": {},
"data": "{\"greeting\": \"Hello, http.md!\"}",
"files": {},
"form": {},
"headers": {
"Accept": "*/*",
"Accept-Encoding": "br, gzip, deflate",
"Accept-Language": "*",
"Content-Length": "31",
"Content-Type": "application/json",
"Host": "httpbin.org",
"Sec-Fetch-Mode": "cors",
"User-Agent": "node",
"X-Amzn-Trace-Id": "Root=1-682a3111-131bcbff690b03fd64aa4617"
},
"Accept": "*/*",
"Accept-Encoding": "br, gzip, deflate",
"Accept-Language": "*",
"Content-Length": "31",
"Content-Type": "application/json",
"Host": "httpbin.org",
"Sec-Fetch-Mode": "cors",
"User-Agent": "node",
"X-Amzn-Trace-Id": "Root=1-682ada85-516dfea550431bd2238aa456"
},
"json": {
"greeting": "Hello, http.md!"
},
"origin": "23.96.180.7",
},
"origin": "172.214.199.239",
"url": "https://httpbin.org/post"
}
```
````
_(Note: Actual headers and some response fields might vary.)_
*(Note: Actual headers and some response fields might vary.)*
## Core Concepts
@@ -183,8 +221,8 @@ All requests in a document are executed sequentially from top to bottom by defau
The `::response` directive is used to render the full HTTP response (status line, headers, and body) of an HTTP request.
- **Implicit Last:** If used without any arguments (i.e., `::response`), it renders the response of the most recently defined `http` block above it.
- **Explicit by ID:** You can render the response of a specific request by referencing its ID (see [Request IDs](https://www.google.com/search?q=%23request-ids)).
* **Implicit Last:** If used without any arguments (i.e., `::response`), it renders the response of the most recently defined `http` block above it.
* **Explicit by ID:** You can render the response of a specific request by referencing its ID (see [Request IDs](https://www.google.com/search?q=%23request-ids)).
### Request IDs
@@ -193,23 +231,23 @@ You can assign a unique ID to an `http` request block. This allows you to:
1. Reference its specific response in a `::response` directive.
2. Access its request and response data in [Templating](https://www.google.com/search?q=%23templating-with-handlebars) via the `requests` and `responses` dictionaries.
To add an ID, include `id=yourUniqueId` in the `http` block's info string:
To add an ID, include `#yourUniqueId` or `id=yourUniqueId` in the `http` block's info string:
````markdown
# Document with Multiple Requests
First, create a resource:
```http id=createUser
```http #createUser,yaml,json
POST https://httpbin.org/post
Content-Type: application/json
{"username": "alpha"}
username: alpha
```
Then, fetch a different resource:
```http id=getItem
```http #getItem
GET https://httpbin.org/get?item=123
```
@@ -218,8 +256,99 @@ Response from creating the user:
Response from getting the item:
::response{#getItem}
````
<details>
<summary>Output</summary>
````markdown
# Document with Multiple Requests
First, create a resource:
```http
POST https://httpbin.org/post
Content-Type: application/json
{"username":"alpha"}
```
Then, fetch a different resource:
```http
GET https://httpbin.org/get?item=123
```
Response from creating the user:
```http
HTTP/200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
connection: keep-alive
content-length: 504
content-type: application/json
date: Mon, 19 May 2025 07:15:18 GMT
server: gunicorn/19.9.0
{
"args": {},
"data": "username: alpha",
"files": {},
"form": {},
"headers": {
"Accept": "*/*",
"Accept-Encoding": "br, gzip, deflate",
"Accept-Language": "*",
"Content-Length": "15",
"Content-Type": "application/json",
"Host": "httpbin.org",
"Sec-Fetch-Mode": "cors",
"User-Agent": "node",
"X-Amzn-Trace-Id": "Root=1-682ada85-5841d69c253c03e450c0cfc8"
},
"json": null,
"origin": "172.214.199.239",
"url": "https://httpbin.org/post"
}
```
Response from getting the item:
```http
HTTP/200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
connection: keep-alive
content-length: 385
content-type: application/json
date: Mon, 19 May 2025 07:15:18 GMT
server: gunicorn/19.9.0
{
"args": {
"item": "123"
},
"headers": {
"Accept": "*/*",
"Accept-Encoding": "br, gzip, deflate",
"Accept-Language": "*",
"Host": "httpbin.org",
"Sec-Fetch-Mode": "cors",
"User-Agent": "node",
"X-Amzn-Trace-Id": "Root=1-682ada86-50ccd79351313f742de31921"
},
"origin": "172.214.199.239",
"url": "https://httpbin.org/get?item=123"
}
```
````
</details>
## Templating with Handlebars
`http.md` uses [Handlebars](https://handlebarsjs.com/) for templating, allowing you to create dynamic content within your markdown files. You can inject data from request responses, input variables, and other requests into your HTTP blocks or general markdown text.
@@ -230,33 +359,33 @@ Templating syntax uses double curly braces: `{{expression}}`.
Within your markdown document, the following variables are available in the Handlebars context:
- **`request`** (Object): Details of the most recently processed HTTP request _before_ it's sent.
* **`request`** (Object): Details of the most recently processed HTTP request *before* it's sent.
- `request.method` (String): The HTTP method (e.g., "GET", "POST").
- `request.url` (String): The request URL.
- `request.headers` (Object): An object containing request headers.
- `request.body` (String): The raw request body.
* `request.method` (String): The HTTP method (e.g., "GET", "POST").
* `request.url` (String): The request URL.
* `request.headers` (Object): An object containing request headers.
* `request.body` (String): The raw request body.
- **`response`** (Object): Details of the most recently received HTTP response.
* **`response`** (Object): Details of the most recently received HTTP response.
- `response.status` (Number): The HTTP status code (e.g., 200, 404).
- `response.statusText` (String): The HTTP status message (e.g., "OK", "Not Found").
- `response.headers` (Object): An object containing response headers.
- `response.body` (String/Object): The response body. If the `http` block had the `json` option and the response was valid JSON, this will be a parsed JSON object. Otherwise, it's a raw string.
- `response.rawBody` (String): The raw response body as a string, regardless of parsing.
- _(In case of network errors or non-HTTP errors, `status` and `body` might reflect error information.)_
* `response.status` (Number): The HTTP status code (e.g., 200, 404).
* `response.statusText` (String): The HTTP status message (e.g., "OK", "Not Found").
* `response.headers` (Object): An object containing response headers.
* `response.body` (String/Object): The response body. If the `http` block had the `json` option and the response was valid JSON, this will be a parsed JSON object. Otherwise, it's a raw string.
* `response.rawBody` (String): The raw response body as a string, regardless of parsing.
* *(In case of network errors or non-HTTP errors, `status` and `body` might reflect error information.)*
- **`requests`** (Object): A dictionary mapping request IDs to their respective `request` objects (as defined above).
* **`requests`** (Object): A dictionary mapping request IDs to their respective `request` objects (as defined above).
- Example: `{{requests.createUser.url}}`
* Example: `{{requests.createUser.url}}`
- **`responses`** (Object): A dictionary mapping request IDs to their respective `response` objects (as defined above).
* **`responses`** (Object): A dictionary mapping request IDs to their respective `response` objects (as defined above).
- Example: `{{responses.createUser.status}}`, `{{responses.createUser.body.id}}` (if `body` is a parsed JSON object).
* Example: `{{responses.createUser.status}}`, `{{responses.createUser.body.id}}` (if `body` is a parsed JSON object).
- **`input`** (Object): A dictionary of variables passed to `http.md` via the command line using the `-i` or `--input` flag.
* **`input`** (Object): A dictionary of variables passed to `http.md` via the command line using the `-i` or `--input` flag.
- Example: If you run `http.md dev -i userId=123 -i apiKey=secret myfile.md`, you can use `{{input.userId}}` and `{{input.apiKey}}`.
* Example: If you run `http.md dev -i userId=123 -i apiKey=secret myfile.md`, you can use `{{input.userId}}` and `{{input.apiKey}}`.
### Templating Examples
@@ -279,6 +408,7 @@ GET https://httpbin.org/anything/{{responses.createItem.body.json.name}}
```
::response{#fetchItem}
````
<details>
@@ -300,42 +430,43 @@ Now, let's fetch the item using a (mocked) ID from the response:
GET https://httpbin.org/anything/My New Item
```
```
```http
HTTP/200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
connection: keep-alive
content-length: 451
content-length: 455
content-type: application/json
date: Sun, 18 May 2025 19:12:18 GMT
date: Mon, 19 May 2025 07:15:18 GMT
server: gunicorn/19.9.0
{
"args": {},
"data": "",
"files": {},
"form": {},
"args": {},
"data": "",
"files": {},
"form": {},
"headers": {
"Accept": "*/*",
"Accept-Encoding": "br, gzip, deflate",
"Accept-Language": "*",
"Host": "httpbin.org",
"Sec-Fetch-Mode": "cors",
"User-Agent": "node",
"X-Amzn-Trace-Id": "Root=1-682a3112-4bbb29111129c1556c487ca1"
},
"json": null,
"method": "GET",
"origin": "23.96.180.7",
"Accept": "*/*",
"Accept-Encoding": "br, gzip, deflate",
"Accept-Language": "*",
"Host": "httpbin.org",
"Sec-Fetch-Mode": "cors",
"User-Agent": "node",
"X-Amzn-Trace-Id": "Root=1-682ada86-5c212bfd7fd8d81a7749fe52"
},
"json": null,
"method": "GET",
"origin": "172.214.199.239",
"url": "https://httpbin.org/anything/My New Item"
}
```
````
</details>
_(Note: `httpbin.org/post` wraps the JSON sent in a "json" field in its response. If your API returns the ID directly at the root of the JSON body, you'd use `{{responses.createItem.body.id}}` assuming the `createItem` request had the `json` option.)_
*(Note: `httpbin.org/post` wraps the JSON sent in a "json" field in its response. If your API returns the ID directly at the root of the JSON body, you'd use `{{responses.createItem.body.id}}` assuming the `createItem` request had the `json` option.)*
**2. Displaying a status code in markdown text:**
@@ -344,7 +475,7 @@ _(Note: `httpbin.org/post` wraps the JSON sent in a "json" field in its response
GET https://httpbin.org/status/201
```
The request to `/status/201` completed with status code: \*\*\*\*.
The request to `/status/201` completed with status code: ****.
````
## Managing Documents
@@ -362,9 +493,10 @@ The requests from the embedded document are processed, and their `request` and `
Assume `_shared_requests.md` contains:
````markdown
```http id=sharedGetRequest
```http #sharedGetRequest
GET https://httpbin.org/get
```
````
Then, in `main.md`:
@@ -376,7 +508,7 @@ Let's include some shared requests:
::md[./_shared_requests.md]
The shared GET request returned:
The shared GET request returned: {{response.statusText}}
Now, a request specific to this document:
@@ -384,12 +516,76 @@ Now, a request specific to this document:
POST https://httpbin.org/post
Content-Type: application/json
{"dataFromMain": "someValue", "sharedUrl": ""}
{"dataFromMain": "someValue", "sharedUrl": "{{requests.sharedGetRequest.url}}"}
```
::response
````
<details>
<summary>Output</summary>
````markdown
# Main Document
Let's include some shared requests:
```http
GET https://httpbin.org/get
```
The shared GET request returned: OK
Now, a request specific to this document:
```http
POST https://httpbin.org/post
Content-Type: application/json
{"dataFromMain": "someValue", "sharedUrl": "https://httpbin.org/get"}
```
```http
HTTP/200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
connection: keep-alive
content-length: 644
content-type: application/json
date: Mon, 19 May 2025 07:15:18 GMT
server: gunicorn/19.9.0
{
"args": {},
"data": "{\"dataFromMain\": \"someValue\", \"sharedUrl\": \"https://httpbin.org/get\"}",
"files": {},
"form": {},
"headers": {
"Accept": "*/*",
"Accept-Encoding": "br, gzip, deflate",
"Accept-Language": "*",
"Content-Length": "69",
"Content-Type": "application/json",
"Host": "httpbin.org",
"Sec-Fetch-Mode": "cors",
"User-Agent": "node",
"X-Amzn-Trace-Id": "Root=1-682ada86-4c99fed83b21605713289d8a"
},
"json": {
"dataFromMain": "someValue",
"sharedUrl": "https://httpbin.org/get"
},
"origin": "172.214.199.239",
"url": "https://httpbin.org/post"
}
```
````
</details>
When `main.md` is processed, `_shared_requests.md` will be embedded, its `sharedGetRequest` will be executed, and its data will be available for templating.
## Advanced Usage
@@ -409,7 +605,7 @@ http.md build mydoc.md output.md -i baseUrl=https://api.production.example.com -
````markdown
```http
GET /users/1
Authorization: Bearer
Authorization: Bearer
```
::response
@@ -421,17 +617,17 @@ Authorization: Bearer
You can configure the behavior of each `http` code block by adding options to its info string, separated by commas.
- `id={your-id}`: Assigns a unique ID to the request. This ID can be used to reference the request's response in the `::response` directive and in templating variables (`requests.your-id`, `responses.your-id`).
* `id={your-id}`: Assigns a unique ID to the request. This ID can be used to reference the request's response in the `::response` directive and in templating variables (`requests.your-id`, `responses.your-id`).
- Example: ` ```http id=getUser,json `
* Example: ` ```http id=getUser,json `
- `json`: If present, `http.md` will attempt to parse the **response body** as JSON. If successful, `response.body` (and `responses.id.body`) will be the parsed JavaScript object/array, making it easier to access its properties in templates (e.g., `{{response.body.fieldName}}`).
* `json`: If present, `http.md` will attempt to parse the **response body** as JSON. If successful, `response.body` (and `responses.id.body`) will be the parsed JavaScript object/array, making it easier to access its properties in templates (e.g., `{{response.body.fieldName}}`).
- Example: ` ```http json `
* Example: ` ```http json `
- `yaml`: If present, the **request body** written in YAML format within the code block will be automatically converted to JSON before the request is sent. This allows for writing complex request bodies in a more human-readable YAML syntax. You should still set the `Content-Type` header appropriately (e.g., to `application/json`) if the server expects JSON.
* `yaml`: If present, the **request body** written in YAML format within the code block will be automatically converted to JSON before the request is sent. This allows for writing complex request bodies in a more human-readable YAML syntax. You should still set the `Content-Type` header appropriately (e.g., to `application/json`) if the server expects JSON.
- Example:
* Example:
````markdown
```http yaml
@@ -446,20 +642,20 @@ You can configure the behavior of each `http` code block by adding options to it
```
````
- `disable`: If present, the HTTP request will **not** be executed. No actual network call will be made. The corresponding `response` variable will be undefined or empty, and `::response` will typically render a "Request disabled" message or similar.
* `disable`: If present, the HTTP request will **not** be executed. No actual network call will be made. The corresponding `response` variable will be undefined or empty, and `::response` will typically render a "Request disabled" message or similar.
- Example: ` ```http disable `
* Example: ` ```http disable `
- `hidden`: If present, the `http` code block itself will **not be included** in the rendered output document. However, the request _is still made_ (unless `disable` is also specified), and its response data can be used in templates or displayed with an explicit `::response{#id}` directive. This is useful for prerequisite requests (like authentication) whose details you don't want to clutter the main documentation.
* `hidden`: If present, the `http` code block itself will **not be included** in the rendered output document. However, the request *is still made* (unless `disable` is also specified), and its response data can be used in templates or displayed with an explicit `::response{#id}` directive. This is useful for prerequisite requests (like authentication) whose details you don't want to clutter the main documentation.
- Example: ` ```http id=authRequest,hidden `
* Example: ` ```http id=authRequest,hidden `
**Combined Example:**
````markdown
```http id=complexRequest,json,yaml,hidden
POST /data
X-API-Key:
X-API-Key:
Content-Type: application/json
# Request body written in YAML, will be converted to JSON
@@ -478,12 +674,12 @@ Directives can also have options, specified similarly.
#### `::response` Directive Options
- `id={id}` (or `#{id}` as a shorthand): Renders the output of a specific request identified by `{id}`.
- Example: `::response{#getUser}` or `::response{id=getUser}`
- `yaml`: Renders the (typically JSON) response body formatted as YAML. This is for display purposes.
- Example: `::response{yaml}`
- `truncate={chars}`: Truncates the displayed **response body** to the specified number of characters. Headers and status line are not affected.
- Example: `::response{truncate=100}`
* `id={id}` (or `#{id}` as a shorthand): Renders the output of a specific request identified by `{id}`.
* Example: `::response{#getUser}` or `::response{id=getUser}`
* `yaml`: Renders the (typically JSON) response body formatted as YAML. This is for display purposes.
* Example: `::response{yaml}`
* `truncate={chars}`: Truncates the displayed **response body** to the specified number of characters. Headers and status line are not affected.
* Example: `::response{truncate=100}`
**Combined Example for `::response`:**
`::response{#getUser,yaml,truncate=500}` - Displays the response for request `getUser`, formats its body as YAML, and truncates the body display to 500 characters.
@@ -492,21 +688,21 @@ Directives can also have options, specified similarly.
The `::md` directive embeds another markdown document.
- **File Path:** The first argument (required) is the path to the markdown file to embed.
- Example: `::md[./includes/authentication.md]`
- `hidden`: If present, the actual content (markdown) of the embedded document will not be rendered in the output. However, any `http` requests within the embedded document _are still processed_, and their `request` and `response` data become available in the parent document's templating context (via `requests.id` and `responses.id`). This is useful if you only want to execute the requests from an included file (e.g., a common setup sequence) and use their results, without displaying the embedded file's content.
- Example: `::md[./setup_requests.md]{hidden}`
* **File Path:** The first argument (required) is the path to the markdown file to embed.
* Example: `::md[./includes/authentication.md]`
* `hidden`: If present, the actual content (markdown) of the embedded document will not be rendered in the output. However, any `http` requests within the embedded document *are still processed*, and their `request` and `response` data become available in the parent document's templating context (via `requests.id` and `responses.id`). This is useful if you only want to execute the requests from an included file (e.g., a common setup sequence) and use their results, without displaying the embedded file's content.
* Example: `::md[./setup_requests.md]{hidden}`
#### `::input[{name}]` Directive Options
The `::input` directive is used to declare expected input variables
- **Variable Name:** The first argument (required) is the name of the variable
- Example: `::input[myVariable]` will define `input.myVariable`
- `required`: If present it will require that the variable is provided
- `default={value}`: Defines the default value if no value has been provided
- `format=string|number|bool|json|date`: If provided the value will be parsed using the specified format
- \`\`
* **Variable Name:** The first argument (required) is the name of the variable
* Example: `::input[myVariable]` will define `input.myVariable`
* `required`: If present it will require that the variable is provided
* `default={value}`: Defines the default value if no value has been provided
* `format=string|number|bool|json|date`: If provided the value will be parsed using the specified format
* \`\`
## Command-Line Interface (CLI)
@@ -516,10 +712,10 @@ The `http.md` tool provides the following commands:
Processes the `<source_file.md>`, executes all HTTP requests, resolves templates, and prints the resulting markdown to the **terminal (stdout)**.
- **Purpose:** Useful for live development and quick previews.
- **Options:**
- `--watch`: Monitors the `<source_file.md>` (and any embedded files) for changes. On detection of a change, it automatically re-processes and re-renders the output to the terminal.
- `-i <key=value>`, `--input <key=value>`: Defines an input variable for templating (see [Using Input Variables](https://www.google.com/search?q=%23using-input-variables)). Can be specified multiple times for multiple variables.
* **Purpose:** Useful for live development and quick previews.
* **Options:**
* `--watch`: Monitors the `<source_file.md>` (and any embedded files) for changes. On detection of a change, it automatically re-processes and re-renders the output to the terminal.
* `-i <key=value>`, `--input <key=value>`: Defines an input variable for templating (see [Using Input Variables](https://www.google.com/search?q=%23using-input-variables)). Can be specified multiple times for multiple variables.
**Example:**
@@ -531,10 +727,10 @@ http.md dev api_tests.md --watch -i host=localhost:3000
Processes the `<source_file.md>`, executes all HTTP requests, resolves templates, and saves the resulting markdown to `<output_file.md>`.
- **Purpose:** Generates a static, shareable markdown file with all dynamic content resolved. Ideal for version control, static site generation, or distributing documentation.
- **Options:**
- `--watch`: Monitors the `<source_file.md>` (and any embedded files) for changes. On detection of a change, it automatically re-processes and re-builds the `<output_file.md>`.
- `-i <key=value>`, `--input <key=value>`: Defines an input variable for templating.
* **Purpose:** Generates a static, shareable markdown file with all dynamic content resolved. Ideal for version control, static site generation, or distributing documentation.
* **Options:**
* `--watch`: Monitors the `<source_file.md>` (and any embedded files) for changes. On detection of a change, it automatically re-processes and re-builds the `<output_file.md>`.
* `-i <key=value>`, `--input <key=value>`: Defines an input variable for templating.
**Example:**