What Are AI-Powered ESM Modules on unpkg.ai and How Do You Use Them?

unpkg.ai generates JavaScript ES modules on demand from a prompt embedded in the URL, then serves them as importable .js files. You use one by writing a function signature (or a short description) into a URL path and importing it directly in your code — no signup, API keys, or authentication required, per the site. It fits rapid prototyping, dynamic plugin systems, and "top-down" coding where you declare the interface you want and let an LLM fill in the implementation. It is not a fit for anything where you need reviewed, versioned, or offline-available code.

How the URL pattern works

The core endpoint is:

GET /esm/{url-encoded-prompt}.js

The prompt is the module's interface, written as a function signature. Special characters like ?, :, {, and } must be URL-encoded. The response is a JavaScript module you import like any other ESM file.

Example request:

https://unpkg.ai/esm/formatCurrency(amount:number,currency%3F:string):string.js

Breaking that down:

Importing and calling a generated module

Once you have the URL, import the named export and call it:

import { formatCurrency } from 'https://unpkg.ai/esm/formatCurrency(amount:number,currency%3F:string):string.js';

console.log(formatCurrency(1234.56, 'EUR')); // "€1,234.56"

The module is fetched over the network at import time (or bundled, depending on your toolchain), so the first load depends on the service being reachable and the LLM producing valid code.

Optional parameters: model and seed

Two query-style options are documented:

• model — choose the AI model, e.g. gpt-4 or claude-3. Optional.
• seed — a number that makes output deterministic for the same prompt, e.g. 12345. Optional.

Use seed when you want the same generated module each time — useful for caching, tests, or reproducible builds. Without it, the same prompt may yield different implementations.

A practical example: password generator

The site's example declares a richer signature with an options object and a structured return type:

import { generatePassword } from 'https://unpkg.ai/esm/generatePassword(options%3F:{length%3F:number,symbols%3F:boolean,numbers%3F:boolean,uppercase%3F:boolean,lowercase%3F:boolean}):{password:string,strength:number,feedback:string[]}.js';

const result = generatePassword({ length: 16, symbols: true });
// { password: 'K#9m$L2pQ!7vX8nR', strength: 95, feedback: ['Very strong'] }

The declared return shape ({password, strength, feedback}) tells the model what to produce. The more precisely you specify types and structure in the signature, the more predictable the generated module tends to be.

Other documented examples follow the same pattern: calculateTip returning {tip, total, perPerson}, generatePalette returning a color scheme object, and initMinesweeper returning {start, reset, getStats} for a DOM-mounted game.

When this approach makes sense — and when it doesn't

Good fit:

• Prototyping where you want a working function now and will refine later.
• Dynamic plugin systems that load modules by URL at runtime.
• Top-down development: define the API surface first, generate the body second.

Poor fit:

• Production code needing review, tests, and pinned versions.
• Offline or air-gapped environments — every import is a network fetch.
• Security-sensitive logic: generated code is LLM output and should be inspected before you trust it.

Common snags

• Encoding errors. An unencoded ? or : breaks the URL. Encode optional markers as %3F and keep the signature otherwise intact.
• Signature drift. Vague prompts produce modules that don't match your expected return shape. Spell out parameter types and the return type.
• Non-determinism. If a module changes between loads, add a seed.
• Runtime dependency. The import resolves only while the service is reachable; plan a fallback or vendor the generated file if uptime matters.

The site lists no pricing or login requirements, so treat availability and rate behavior as things to verify against the live service rather than assume.