Project creation
Create a production-oriented TypeScript starter that composes the White Label packages with one canonical tagged-HTML template path.
npx generator-white-label create my-projectnpm install --global generator-white-label
white-label create my-projectimport {createProject} from 'generator-white-label';white-label create writes the canonical tagged-template White Label starter.
Project creation refuses an existing non-empty destination before scaffold files are written. Existing empty directories are allowed.
npx generator-white-label create my-projectcreateProject() is the canonical creation engine. The CLI is an adapter around the same implementation rather than a separate scaffold path, so both share the same destination-overwrite protection.
A successful call resolves after scaffold files and package metadata are written. File-system failures or a non-empty destination reject the promise rather than returning a status object.
import {createProject} from 'generator-white-label';
await createProject({destination: './my-project'});The generated application demonstrates Router → Mediator → Model → View as composable responsibilities, not mandatory framework layers. Static sections remain static; features use only the pieces they need.
Generated page and View templates use white-label-view/html tagged templates. Applications remain free to replace that renderer after generation.
The generator is for new projects and intentionally rejects non-empty destinations. To modernize an existing server-rendered/CMS/commerce application, install the runtime packages it needs directly instead of merging a generated scaffold into host code.
Generated projects include a provider-neutral server/handler.ts example built around the Web Request and Response APIs. The handler composes request-scoped Router, Mediator, Model, and white-label-view/server instances, then cleans them up before the invocation completes.
Keep cloud adapters thin: translate a provider-specific event into a Web Request when necessary, call the shared handler, and translate the Response back only if the platform requires it. No AWS, Vercel, Netlify, Cloudflare, Azure, or other provider SDK is required by White Label.
Generated-project tests exercise warm and concurrent request isolation, DOM-free execution, a Web-target portability bundle budget, and a fresh-process handler-import budget. Those checks are portability and regression guards, not blanket edge-runtime compatibility claims.
const response = await handleRequest(
new Request('https://example.com/hello?name=Ada')
);white-label create <destination>Create the canonical tagged-template project in a missing or empty target directory without overwriting existing user files.
white-label --helpShow command usage.
createProject(options)Write the canonical White Label scaffold using the same implementation and overwrite protection as the CLI.
| Parameter | Type | Default | Description |
|---|---|---|---|
destination | string | — | Required filesystem destination; missing or empty is allowed, non-empty is rejected. |
fileSystem | ScaffoldFileSystem | — | Optional filesystem adapter for controlled integrations and tests. |
createSiteManifest()Return the package manifest written into generated White Label projects.
CreateProjectOptionsTypeScript options contract for createProject().
ScaffoldFileSystemTypeScript filesystem adapter contract used by createProject() for copying files and writing JSON.
The generated application uses strict TypeScript and the real White Label runtime packages.
Generated templates use white-label-view/html tagged templates.
Generated tagged HTML escapes ordinary interpolations and uses explicit trusted-markup boundaries. Applications still validate URL, CSS, and other context-sensitive semantics.
The canonical createProject() engine rejects non-empty destinations and uses no-clobber scaffold writes so files or symlinks created after the initial destination check are not overwritten.
The generator creates new projects; generated application behavior belongs to the runtime packages and application code. Existing applications should adopt runtime packages directly rather than using the generator as a migration tool.
Future creation integrations should call createProject() rather than copy templates or reimplement scaffold logic.