htmlship 0.3.0__tar.gz → 0.3.1__tar.gz

{htmlship-0.3.0 → htmlship-0.3.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: htmlship
-Version: 0.3.0
+Version: 0.3.1
 Summary: Host and share HTML pages from LLMs and coding agents in one line.
 Project-URL: Homepage, https://htmlship.com
 Project-URL: Repository, https://github.com/htmlship/htmlship
@@ -136,36 +136,44 @@ The CLI stores owner keys in `~/.htmlship/keys.json` so `update`, `delete`, and
 
 ## Deploy built apps
 
-`deploy` builds a modern frontend project (React, Vite, Svelte, etc.) and publishes the **compiled** app as a single self-contained page — no separate asset hosting required.
+`deploy` builds a modern frontend project (React, Vite, Svelte, Next.js, …) **locally** and publishes the compiled output. Single-page apps are inlined into one self-contained page; multi-file sites (Next.js static export — auto-detected — Astro, Docusaurus, VitePress, …) are hosted as a file tree at `view.htmlship.com/{slug}/`. No separate asset hosting required either way.
 
 ```bash
-htmlship deploy ./my-app            # detect build script, build, inline, publish
-htmlship deploy --dry-run           # build + inline, but don't publish (inspect first)
+htmlship deploy ./my-app                         # SPA -> one inlined page
+htmlship deploy ./my-next-app                    # Next.js -> multi-file site (auto-detected)
+htmlship deploy ./my-app --site --out dist       # force multi-file hosting (Astro, etc.)
+htmlship deploy ./my-app --single-file           # force single-file inlining
+htmlship deploy ./my-app --password "demo-pass"  # password-protect the deploy
+htmlship deploy --dry-run                         # build, but don't publish (inspect first)
 htmlship deploy --build-cmd "vite build" --out dist
-npx htmlship deploy ./my-app        # same, no install
+npx htmlship deploy ./my-app                      # same, no install
 ```
 
 How it works:
 
 1. **The build runs locally, on your machine — never on the server.** `deploy` detects your package manager (npm/pnpm/yarn/bun) and runs the `build` script (falling back to `build:prod`, or `--build-cmd` to override). This is what keeps the service from ever executing untrusted build steps.
-2. The build output (`dist/` or `build/`, or `--out`) is **inlined into one HTML file**: scripts and stylesheets are embedded, and referenced images/icons/fonts become data URIs. The result must be ≤ 10 MB.
-3. It's published with `sandbox_mode: "relaxed"` so the app's JavaScript can run (see [Rendering](#rendering)).
+2. **Single-file** (default for SPAs): the output (`dist/`, `build/`, or `--out`) is inlined into one HTML file — scripts and stylesheets embedded, images/icons/fonts as data URIs — and published with `sandbox_mode: "relaxed"`.
+3. **Multi-file** (Next.js auto-detected, or `--site`): the whole output tree is uploaded as a base64 file manifest to `POST /api/v1/sites` and served at `view.htmlship.com/{slug}/`, each response carrying a path-scoped per-slug sandbox CSP.
+
+Both kinds run with relaxed sandboxing (see [Rendering](#rendering)) and are capped at 10 MB. `--single-file` and `--site` force a mode when you don't want the auto-detected one.
 
 The same flow is available programmatically (Python library) and via the `deploy_project` MCP tool:
 
 ```python
 import htmlship
 
-# Library: build ./my-app locally and publish the compiled app
-page = htmlship.HTMLShipClient().deploy("./my-app", expires_in=1440)
+# build ./my-app locally and publish (auto-detects single-file vs. multi-file site)
+page = htmlship.HTMLShipClient().deploy_project("./my-app", password="demo-pass", expires_in=1440)
 print(page.url)
 ```
 
-**Relaxed-mode limits (by design):** a deployed app runs in an isolated, opaque origin and **cannot** make network requests (`connect-src 'none'`), read cookies, access other pages, or use `eval`. It's intended for self-contained client-side apps and demos — not for apps that call external APIs at runtime.
+**Relaxed-mode limits (by design):** a deployed app runs in an isolated, opaque origin and **cannot** make network requests (`connect-src 'none'`), read cookies, access other pages, or use `eval`. For a multi-file Next.js site that means client-side data fetches fail closed and Next falls back to full-page navigation — links still work, runtime API calls don't. It's intended for self-contained client-side apps, demos, and static content — not for apps that call external APIs at runtime.
 
-**What `deploy` supports:** single-page static apps that build to one `index.html` plus assets — Vite, Create React App, Astro (static), SvelteKit (`adapter-static`), Vue CLI, plain static-site generators. `deploy` auto-detects `dist/`, `build/`, and `out/` with no flags.
+**What `deploy` supports:**
 
-**Next.js note:** a default `next build` produces a *server* build in `.next/`, which is not statically hostable anywhere — and renaming it via `distDir` doesn't change that. To deploy a Next.js app you must add `output: "export"` to `next.config` (it emits a static `out/` folder, which `deploy` picks up automatically). Apps that rely on middleware, SSR, or multi-route i18n can't be statically exported and aren't a fit for single-file hosting.
+- **Single-page apps** that build to one `index.html` plus assets — Vite, Create React App, SvelteKit (`adapter-static`), Vue CLI, plain static-site generators. Auto-detects `dist/`, `build/`, and `out/` with no flags.
+- **Next.js** (auto-detected): the CLI transparently builds a **static export based at the slug path** — you don't edit `next.config`. The app must be statically exportable (no middleware, SSR, or server features). One exception: a `next.config.ts` can't be rewritten automatically yet, so `deploy` asks you to set `output: "export"` plus `basePath`/`assetPrefix = "/__htmlship_base__"` yourself, or convert the config to `next.config.mjs`.
+- **Other multi-file frameworks** via `--site` (Astro, Docusaurus, VitePress, multi-page builds): build with your framework's base path set to `/__htmlship_base__` (e.g. Astro's `base`, or `vite build --base=/__htmlship_base__/`) so root-absolute asset URLs resolve under `/{slug}/`; the server rewrites that placeholder to the real slug at upload. Automatic base injection is currently Next.js-only.
 
 ## API
 
@@ -176,6 +184,7 @@ Base URL: `https://api.htmlship.com`.
 | `GET` | `/health` | Health check with service version. |
 | `GET` | `/version` | Service version. |
 | `POST` | `/api/v1/pages` | Create a page. |
+| `POST` | `/api/v1/sites` | Upload a multi-file static site (base64 file manifest); served at `view.htmlship.com/{slug}/`. |
 | `GET` | `/api/v1/pages/{slug}` | Fetch page metadata. |
 | `PATCH` | `/api/v1/pages/{slug}` | Replace HTML or title. Requires `X-Owner-Key`. |
 | `DELETE` | `/api/v1/pages/{slug}` | Soft-delete a page. Requires `X-Owner-Key`. |
@@ -202,7 +211,7 @@ Notes:
 - `sandbox_mode` accepts `strict` (default) or `relaxed`. `strict` blocks all scripts; `relaxed` lets the page's own inline scripts run inside an isolated, opaque origin (used by `deploy` for compiled apps). See [Rendering](#rendering).
 - Password-protected views set a signed, HTTP-only session cookie after the correct password is submitted.
 
-There is no server-side build endpoint, by design: builds always run on the client (see [Deploy built apps](#deploy-built-apps)). The API only ever receives already-inlined HTML, so deploying via the API is simply a `POST /api/v1/pages` with `"sandbox_mode": "relaxed"`.
+There is no server-side build endpoint, by design: builds always run on the client (see [Deploy built apps](#deploy-built-apps)). The API only ever receives already-built output — single-file deploys are a `POST /api/v1/pages` with `"sandbox_mode": "relaxed"`; multi-file sites are a `POST /api/v1/sites` with a base64 file manifest, served per-slug at `view.htmlship.com/{slug}/`.
 
 ## Rendering
 
@@ -218,11 +227,13 @@ Rendered HTML is served from `view.htmlship.com/{slug}`. **Strict** pages (the d
 
 **Relaxed** pages (`sandbox_mode: "relaxed"`, used by `deploy`) let the page's own inline scripts run but isolate them with `Content-Security-Policy: sandbox allow-scripts` — deliberately *without* `allow-same-origin`. That forces an opaque origin, so a deployed app cannot read cookies, touch `localStorage`, or fetch other pages same-origin. `connect-src 'none'` additionally blocks network egress. The body is still served verbatim; isolation is enforced entirely by response headers, with no change to the single-file storage model.
 
+**Multi-file sites** (`deploy` of a Next.js export or `--site`) are served at `view.htmlship.com/{slug}/` from a per-slug file tree. Each response carries the same opaque-origin `sandbox` CSP, additionally path-scoped to `/{slug}/` (`script-src`/`style-src`/`img-src`/`font-src` are pinned to that prefix). Per-slug isolation therefore comes from the CSP, not from the URL path — one slug's scripts can't read another's, and `connect-src 'none'` blocks egress just as for single-file pages.
+
 The app routes by `Host` header:
 
 - `htmlship.com` serves the landing page
 - `api.htmlship.com` serves the API and landing assets
-- `view.htmlship.com/{slug}` serves sandboxed HTML
+- `view.htmlship.com/{slug}` serves a sandboxed single page; `view.htmlship.com/{slug}/…` serves a multi-file site's tree
 
 For local development without DNS, append `?_host=view.htmlship.com` (or your configured view host) to spoof the host header, for example:
 

{htmlship-0.3.0 → htmlship-0.3.1}/README.md

@@ -91,36 +91,44 @@ The CLI stores owner keys in `~/.htmlship/keys.json` so `update`, `delete`, and
 
 ## Deploy built apps
 
-`deploy` builds a modern frontend project (React, Vite, Svelte, etc.) and publishes the **compiled** app as a single self-contained page — no separate asset hosting required.
+`deploy` builds a modern frontend project (React, Vite, Svelte, Next.js, …) **locally** and publishes the compiled output. Single-page apps are inlined into one self-contained page; multi-file sites (Next.js static export — auto-detected — Astro, Docusaurus, VitePress, …) are hosted as a file tree at `view.htmlship.com/{slug}/`. No separate asset hosting required either way.
 
 ```bash
-htmlship deploy ./my-app            # detect build script, build, inline, publish
-htmlship deploy --dry-run           # build + inline, but don't publish (inspect first)
+htmlship deploy ./my-app                         # SPA -> one inlined page
+htmlship deploy ./my-next-app                    # Next.js -> multi-file site (auto-detected)
+htmlship deploy ./my-app --site --out dist       # force multi-file hosting (Astro, etc.)
+htmlship deploy ./my-app --single-file           # force single-file inlining
+htmlship deploy ./my-app --password "demo-pass"  # password-protect the deploy
+htmlship deploy --dry-run                         # build, but don't publish (inspect first)
 htmlship deploy --build-cmd "vite build" --out dist
-npx htmlship deploy ./my-app        # same, no install
+npx htmlship deploy ./my-app                      # same, no install
 ```
 
 How it works:
 
 1. **The build runs locally, on your machine — never on the server.** `deploy` detects your package manager (npm/pnpm/yarn/bun) and runs the `build` script (falling back to `build:prod`, or `--build-cmd` to override). This is what keeps the service from ever executing untrusted build steps.
-2. The build output (`dist/` or `build/`, or `--out`) is **inlined into one HTML file**: scripts and stylesheets are embedded, and referenced images/icons/fonts become data URIs. The result must be ≤ 10 MB.
-3. It's published with `sandbox_mode: "relaxed"` so the app's JavaScript can run (see [Rendering](#rendering)).
+2. **Single-file** (default for SPAs): the output (`dist/`, `build/`, or `--out`) is inlined into one HTML file — scripts and stylesheets embedded, images/icons/fonts as data URIs — and published with `sandbox_mode: "relaxed"`.
+3. **Multi-file** (Next.js auto-detected, or `--site`): the whole output tree is uploaded as a base64 file manifest to `POST /api/v1/sites` and served at `view.htmlship.com/{slug}/`, each response carrying a path-scoped per-slug sandbox CSP.
+
+Both kinds run with relaxed sandboxing (see [Rendering](#rendering)) and are capped at 10 MB. `--single-file` and `--site` force a mode when you don't want the auto-detected one.
 
 The same flow is available programmatically (Python library) and via the `deploy_project` MCP tool:
 
 ```python
 import htmlship
 
-# Library: build ./my-app locally and publish the compiled app
-page = htmlship.HTMLShipClient().deploy("./my-app", expires_in=1440)
+# build ./my-app locally and publish (auto-detects single-file vs. multi-file site)
+page = htmlship.HTMLShipClient().deploy_project("./my-app", password="demo-pass", expires_in=1440)
 print(page.url)
 ```
 
-**Relaxed-mode limits (by design):** a deployed app runs in an isolated, opaque origin and **cannot** make network requests (`connect-src 'none'`), read cookies, access other pages, or use `eval`. It's intended for self-contained client-side apps and demos — not for apps that call external APIs at runtime.
+**Relaxed-mode limits (by design):** a deployed app runs in an isolated, opaque origin and **cannot** make network requests (`connect-src 'none'`), read cookies, access other pages, or use `eval`. For a multi-file Next.js site that means client-side data fetches fail closed and Next falls back to full-page navigation — links still work, runtime API calls don't. It's intended for self-contained client-side apps, demos, and static content — not for apps that call external APIs at runtime.
 
-**What `deploy` supports:** single-page static apps that build to one `index.html` plus assets — Vite, Create React App, Astro (static), SvelteKit (`adapter-static`), Vue CLI, plain static-site generators. `deploy` auto-detects `dist/`, `build/`, and `out/` with no flags.
+**What `deploy` supports:**
 
-**Next.js note:** a default `next build` produces a *server* build in `.next/`, which is not statically hostable anywhere — and renaming it via `distDir` doesn't change that. To deploy a Next.js app you must add `output: "export"` to `next.config` (it emits a static `out/` folder, which `deploy` picks up automatically). Apps that rely on middleware, SSR, or multi-route i18n can't be statically exported and aren't a fit for single-file hosting.
+- **Single-page apps** that build to one `index.html` plus assets — Vite, Create React App, SvelteKit (`adapter-static`), Vue CLI, plain static-site generators. Auto-detects `dist/`, `build/`, and `out/` with no flags.
+- **Next.js** (auto-detected): the CLI transparently builds a **static export based at the slug path** — you don't edit `next.config`. The app must be statically exportable (no middleware, SSR, or server features). One exception: a `next.config.ts` can't be rewritten automatically yet, so `deploy` asks you to set `output: "export"` plus `basePath`/`assetPrefix = "/__htmlship_base__"` yourself, or convert the config to `next.config.mjs`.
+- **Other multi-file frameworks** via `--site` (Astro, Docusaurus, VitePress, multi-page builds): build with your framework's base path set to `/__htmlship_base__` (e.g. Astro's `base`, or `vite build --base=/__htmlship_base__/`) so root-absolute asset URLs resolve under `/{slug}/`; the server rewrites that placeholder to the real slug at upload. Automatic base injection is currently Next.js-only.
 
 ## API
 
@@ -131,6 +139,7 @@ Base URL: `https://api.htmlship.com`.
 | `GET` | `/health` | Health check with service version. |
 | `GET` | `/version` | Service version. |
 | `POST` | `/api/v1/pages` | Create a page. |
+| `POST` | `/api/v1/sites` | Upload a multi-file static site (base64 file manifest); served at `view.htmlship.com/{slug}/`. |
 | `GET` | `/api/v1/pages/{slug}` | Fetch page metadata. |
 | `PATCH` | `/api/v1/pages/{slug}` | Replace HTML or title. Requires `X-Owner-Key`. |
 | `DELETE` | `/api/v1/pages/{slug}` | Soft-delete a page. Requires `X-Owner-Key`. |
@@ -157,7 +166,7 @@ Notes:
 - `sandbox_mode` accepts `strict` (default) or `relaxed`. `strict` blocks all scripts; `relaxed` lets the page's own inline scripts run inside an isolated, opaque origin (used by `deploy` for compiled apps). See [Rendering](#rendering).
 - Password-protected views set a signed, HTTP-only session cookie after the correct password is submitted.
 
-There is no server-side build endpoint, by design: builds always run on the client (see [Deploy built apps](#deploy-built-apps)). The API only ever receives already-inlined HTML, so deploying via the API is simply a `POST /api/v1/pages` with `"sandbox_mode": "relaxed"`.
+There is no server-side build endpoint, by design: builds always run on the client (see [Deploy built apps](#deploy-built-apps)). The API only ever receives already-built output — single-file deploys are a `POST /api/v1/pages` with `"sandbox_mode": "relaxed"`; multi-file sites are a `POST /api/v1/sites` with a base64 file manifest, served per-slug at `view.htmlship.com/{slug}/`.
 
 ## Rendering
 
@@ -173,11 +182,13 @@ Rendered HTML is served from `view.htmlship.com/{slug}`. **Strict** pages (the d
 
 **Relaxed** pages (`sandbox_mode: "relaxed"`, used by `deploy`) let the page's own inline scripts run but isolate them with `Content-Security-Policy: sandbox allow-scripts` — deliberately *without* `allow-same-origin`. That forces an opaque origin, so a deployed app cannot read cookies, touch `localStorage`, or fetch other pages same-origin. `connect-src 'none'` additionally blocks network egress. The body is still served verbatim; isolation is enforced entirely by response headers, with no change to the single-file storage model.
 
+**Multi-file sites** (`deploy` of a Next.js export or `--site`) are served at `view.htmlship.com/{slug}/` from a per-slug file tree. Each response carries the same opaque-origin `sandbox` CSP, additionally path-scoped to `/{slug}/` (`script-src`/`style-src`/`img-src`/`font-src` are pinned to that prefix). Per-slug isolation therefore comes from the CSP, not from the URL path — one slug's scripts can't read another's, and `connect-src 'none'` blocks egress just as for single-file pages.
+
 The app routes by `Host` header:
 
 - `htmlship.com` serves the landing page
 - `api.htmlship.com` serves the API and landing assets
-- `view.htmlship.com/{slug}` serves sandboxed HTML
+- `view.htmlship.com/{slug}` serves a sandboxed single page; `view.htmlship.com/{slug}/…` serves a multi-file site's tree
 
 For local development without DNS, append `?_host=view.htmlship.com` (or your configured view host) to spoof the host header, for example:
 

{htmlship-0.3.0 → htmlship-0.3.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "htmlship"
-version = "0.3.0"
+version = "0.3.1"
 description = "Host and share HTML pages from LLMs and coding agents in one line."
 readme = "README.md"
 requires-python = ">=3.12"

htmlship-0.3.1/src/htmlship/_version.py

@@ -0,0 +1 @@
+__version__ = "0.3.1"

htmlship-0.3.1/src/htmlship_mcp/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.3.1"

htmlship-0.3.1/src/htmlship_server/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.3.1"

htmlship-0.3.0/src/htmlship/_version.py

@@ -1 +0,0 @@
-__version__ = "0.3.0"

htmlship-0.3.0/src/htmlship_mcp/__init__.py

@@ -1 +0,0 @@
-__version__ = "0.3.0"

htmlship-0.3.0/src/htmlship_server/__init__.py

@@ -1 +0,0 @@
-__version__ = "0.3.0"