Libraries in mini apps

A mini app is a React component, so it can use real front-end libraries — charts, icons, Markdown rendering, 3D scenes, date math, and more. There are two ways an app gets a library, and you don’t install anything either way:

• Built-in libraries — a curated set that’s always available. The app just imports them by name, no setup.
• On-demand packages — for anything else on npm, you ask the assistant and it adds the package for you. No command to run.

Both work the same way once they’re in: the app imports the library and uses it. The difference is only whether it was already there or had to be fetched.

Built-in libraries

These come preloaded with every mini app. An app can import any of them by name with zero setup, and the assistant reaches for them by default when it builds something:

• recharts — charts and graphs
• lucide-react — icons
• d3 — data visualization
• three — 3D and WebGL
• dayjs — dates and times
• zod — validating data
• clsx — building className strings
• marked — Markdown → HTML
• dompurify — sanitizing HTML (pairs with marked)
• papaparse — reading and writing CSV
• fuse.js — fuzzy search
• qrcode — QR codes

Tailwind is always on too — apps style themselves with className, no import needed. (react itself is, of course, always there.)

You don't pick these by hand

When you ask the assistant to build an app, it chooses the right built-in library on its own — a chart app gets recharts, an app with icons gets lucide-react. You only think about libraries when you want something that isn’t on this list.

On-demand packages: just ask

For any other npm library, you don’t go find it or run a command — you describe what you want and the assistant adds the package, then writes the component that uses it. It’s the same conversational flow as building anything else:

Build me an app with a confetti button — use canvas-confetti.

Add framer-motion so the cards animate in.

Behind the scenes the assistant fetches the package from npm, bundles it, and makes it importable — then writes the code that imports it. You see the result in the live preview, the same as any other change. To swap or remove a library later, just say so.

Markdown safely

If your app renders Markdown or HTML, the assistant pairs marked (Markdown → HTML) with dompurify to sanitize the result before it’s shown — DOMPurify.sanitize(marked.parse(text)). Always sanitize HTML you inject; the assistant does this for you.

What works in the sandbox — and what doesn’t

Mini apps run walled-in by design. That sandbox has two rules that decide which libraries are usable:

No network access

An app can’t make its own web requests. Libraries that fetch from the internet won’t work inside the sandbox.

No browser storage

There’s no localStorage or IndexedDB. Libraries that persist to the browser have nothing to write to.

So libraries that depend on those two things don’t run in a mini app:

• HTTP clients (like axios) — there’s no network to call.
• Vector maps (like mapbox-gl / maplibre-gl) — they fetch tiles and styles over the network. (Raster maps like leaflet are a special case — see the note below.)
• Cloud / AI SDKs (like openai) — they call out to a service.
• Analytics and realtime clients — same reason.
• Browser-storage helpers — there’s no persistent storage to use.

If you ask for one of these, the assistant won’t quietly add something that can’t work — it tells you the package needs the network or storage and points you at the right tool instead (below).

Maps and external images are grantable

One thing does cross the network wall, on purpose: loading external images, including raster map tiles. A Leaflet map over OpenStreetMap tiles works once you grant the app the tile host — see Maps & external images. (Vector maps still need a two-way connection and usually can’t, which is why mapbox-gl stays on the list above.)

Anything that runs in the app itself is fine: charts, 3D and WebGL (three), animation, parsing, search, math — all of it works, because none of it needs to leave the sandbox.

Reaching data and the outside world

The sandbox blocks an app from talking to the internet directly — but apps aren’t meant to. To store data or do real work, a mini app uses Catalyst itself, not a library:

• Data collections — the app’s storage. This is where “save my entries” or “remember my list” lives, instead of browser storage.
• Workflows — the app’s verbs. Anything that touches the outside world — calling an API, searching the web, generating an image — happens in a workflow the app runs, not in a library inside the app.

An app can only reach the collections and workflows you grant it, which is exactly why the no-network rule is safe rather than limiting: the work that needs the network still happens, just on the Catalyst side where your grants and credentials apply.

Libraries travel with the app

You don’t have to think about dependencies when an app changes hands. When you fork an app, or run one from the store, its libraries come along automatically — a forked or published app already has the same packages it was built with, so it just works. There’s nothing to reinstall.

Related

• Build a mini app — ask for an app (and the libraries it needs) in chat.
• Data & permissions — the sandbox, and the grants that let an app reach data and workflows.
• Store data between runs — collections, the app’s storage in place of browser storage.
• Create & publish an app — fork and store apps that carry their libraries with them.