The toolchain

One source, many artifacts

You write a vanilla custom element. banira reads it once into a Custom Elements Manifest (custom-elements.json) — the ecosystem-standard descriptor — and every other artifact is derived from that single source of truth, so they never drift apart.

• The manifest — banira manifest — IDE autocomplete, Storybook controls, template type-checking.
• Typings — banira types — a .d.ts augmenting HTMLElementTagNameMap.
• Editor data — banira editor-data — VS Code custom-data and JetBrains web-types.
• Docs — banira doc — an HTML page with summary, demos and a full API reference.

The generate pipeline

A typical project regenerates everything from source in one pass:

$ banira manifest src/*.ts        -o custom-elements.json
$ banira types    src/*.ts        -o dist/elements.d.ts
$ banira doc      src/my-button.ts -o docs/my-button.html

The same thing, as a library

Everything the CLI does is available as typed exports, so you can wire banira into your own scripts and build steps.

import { ManifestGenerator, toTypeDefinitions, DocGen } from 'banira';

const manifest = new ManifestGenerator(['src/my-button.ts']).generate();
const dts = toTypeDefinitions(manifest);
const page = await new DocGen('my-button').generate('src/my-button.ts');

Develop and ship

While authoring, banira dev gives you compile-on-save with live reload. For release, banira diff compares two manifests and suggests a semver bump — see CI & release.