Proposal: publish a stable temporary preview from generated apps

Open
  • Is something wrong?
#134 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
typescript, wasm
Domain
api, frontend

Research direction

Start by reading lib/preview/bundle.ts and lib/preview/html.ts to trace how the existing preview bundle and document are built, then review temp.md’s browser integration guide. The issue calls for a focused mocked-API test path covering initial publish, stable-URL updates, revoke, and errors. Done means publishing is explicit, later revisions update the same URL, and a failed revision leaves the last successful preview available.

Written by the indexing model from the issue text.

Description

Problem

LlamaCoder's current Share action links to /share/v2/:messageId. That is useful for sharing one generated message, but it is tied to that specific revision and is rendered through the LlamaCoder application. Continuing to iterate produces a new message rather than updating one standalone preview URL.

Related to #114, but deliberately narrower: this proposal publishes the already-rendered static preview and does not introduce project permissions, deployment configuration, or an AI-assisted release workflow.

It would be useful to have an optional, account-free way to publish the rendered app itself for external review, keep the same URL as the chat evolves, and revoke it when review is finished.

Proposed UX

Add a Publish preview action beside the existing Share action:

  1. The first publish creates a temporary standalone preview and copies its URL.
  2. Later publishes from the same chat update that same URL atomically.
  3. The action shows Open, Copy link, and Revoke after publishing.
  4. The existing message-specific Share flow remains unchanged.

Before the first upload, the UI should disclose that the rendered preview is uploaded to temp.md, is public by default, and normally expires after seven days.

Why this is a small fit for the current renderer

LlamaCoder already has nearly all of the difficult local pieces:

  • lib/preview/bundle.ts produces browser-side JavaScript and CSS with esbuild-wasm.
  • lib/preview/html.ts produces a complete HTML document.
  • The renderer already supports a single-file bundle mode and a CDN-safe vendor path.
  • Generated code runs in a sandboxed iframe without same-origin access to the parent application.

The integration can therefore publish one generated index.html; it does not need to send source code, proxy through the LlamaCoder backend, or add a general deployment-provider abstraction.

Suggested implementation

  • Extract a small reusable buildPublishablePreview(files) helper from the existing bundle/srcdoc path.
  • Use the browser-capable temp.md publish-session API to upload index.html.
  • Persist only the scoped temp.md preview state, keyed by chat ID, in LlamaCoder-owned browser storage. Never put upload/update capabilities in URLs, rendered output, telemetry, toast messages, or logs.
  • Reuse the saved update capability for later revisions so the canonical URL stays stable.
  • Treat publishing as an explicit action; generation should never upload automatically.
  • Preserve the last successful preview if bundling or uploading a later revision fails.
  • Include focused tests for initial publish, same-URL update, revoke, disclosure, and error handling using a mocked API.

The browser API uses wildcard CORS without cookies and capability-scoped bearer tokens, so this should not require temp.md accounts, LlamaCoder server secrets, or a backend proxy.

Service disclosure

I maintain temp.md and would implement and support this integration. temp.md provides temporary static previews rather than permanent production hosting. Its browser integration guide and public contract are available at:

If this direction fits LlamaCoder, I can prepare the implementation as a focused PR while keeping the existing Share behavior intact.

Dominant language
TypeScript
Stars
7.1k
Forks
1.7k
Avg merge
4m
Merged PRs (30d)
3

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Nutlope/llamacoder

All issues in Nutlope/llamacoder

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.