Open source packages, crates, and templates from builder.group projects.

Packages

Package	Description	NPM Package
config	Shared TypeScript, ESLint, Prettier, and Vitest configs for Builder Group projects	@blgc/config
ecsify	TypeScript ECS with typed plugins, flexible component storage, queries, and tracking	ecsify
feature-core	Typed .with() feature composition with dependency checks for TypeScript objects	feature-core
feature-fetch	Typed fetch client with tuple results and opt-in REST, OpenAPI, GraphQL, retry, cache	feature-fetch
feature-form	Framework-agnostic reactive form state with Standard Schema validation and triggers	feature-form
feature-logger	Composable console logger with levels, formatting, middleware, and testable output	feature-logger
feature-react	Provider-free React hooks for feature-state and feature-form subscriptions	feature-react
feature-state	Reactive state with computed values and opt-in undo, storage, equality, and queues	feature-state
head-metadata	Typed HTML head metadata extraction for title, meta, link, and custom extractors	head-metadata
openapi-ts-router	Typed Express and Hono routes backed by OpenAPI paths and Standard Schema validation	openapi-ts-router
rollup-presets	Rollup presets for TypeScript libraries with package export discovery and declarations	rollup-presets
tuple-result	Plain TypeScript Result tuples with typed errors, narrowing, helpers, JSON-friendly arrays	tuple-result
validatenv	Typed env validation with Standard Schema validators, built-in parsers, error reports	validatenv
xml-tokenizer	Streaming XML, HTML, and SVG tokenizer with typed tokens, selectors, object helpers	xml-tokenizer

Crates

Crate	Description	Crates.io
mado	macOS active app and window monitoring with browser metadata	mado

Deprecated Packages

These packages live under packages/_deprecated. They remain listed for existing users and historical context, but they are not actively maintained. Prefer the active packages above when starting new work.

Package	Description	NPM Package	Deprecated Since
@blgc/cli	Rollup and esbuild CLI for bundling TypeScript libraries	@blgc/cli	March 9, 2026
@blgc/types	Shared utility, API, and OpenAPI TypeScript types	@blgc/types	May 26, 2026
@blgc/utils	TypeScript utilities for colors, IDs, objects, URLs, and math	@blgc/utils	May 26, 2026
elevenlabs-client	ElevenLabs text-to-speech API client	elevenlabs-client	November 6, 2025
eprel-client	EU EPREL energy label registry API client	eprel-client	May 21, 2026
figma-connect	Typed message bridge between Figma plugin UI iframes and sandbox code	figma-connect	November 6, 2025
google-webfonts-client	Google Web Fonts metadata and font download client	google-webfonts-client	November 6, 2025
kleinanzeigen-client	Kleinanzeigen scraping and listing extraction client	kleinanzeigen-client	November 6, 2025
openapi-express	OpenAPI-typed Express router wrapper with Zod request validation	openapi-express	January 1, 2025
split-flap-board	Web Components for animated split-flap boards	split-flap-board	May 21, 2026
validation-adapter	Universal validation abstraction for Zod, Valibot, and Yup	validation-adapter	May 26, 2026
validation-adapters	Validator adapter implementations for Zod, Valibot, Yup, and Standard Schema	validation-adapters	May 26, 2026
webito	ECS-powered visual web editor with plugin-based customization	webito	May 17, 2026

Templates

Template	Description
desktop-tauri	Tauri desktop app template with React and Specta
web-tanstack	TanStack Start web app template with React and Vite

Examples

See /examples

feature-fetch

• feature-fetch/vanilla/basic

feature-form

• feature-form/react/basic

feature-state

• feature-state/react/basic

openapi-ts-router

• openapi-ts-router/hono/petstore
• openapi-ts-router/express/petstore

xml-tokenizer

• xml-tokenizer/vanilla/playground

FAQ

What does blgc stand for?

blgc stands for BuiLder.Group Community, chosen because similar names like blg, bldr and bgc were already taken.

Why a monorepo?

Keeping all packages in one repository means shared tooling, consistent versioning, and streamlined CI. Cross-package changes are easier to make and keep in sync.

The trade-off is discoverability: individual packages are harder to find through search because they all live under one repo.

Why two package build modes (build vs build:prod)?

pnpm build (development): includes TypeScript declaration maps so IDE navigation goes to source files instead of compiled definitions, and skips minification for easier debugging.

pnpm build:prod (production): smaller output, minification enabled, declaration maps excluded. Declaration maps cause npm publish errors (e.g. EINVALIDTAGNAME in GitHub CLI) so they must be stripped from published packages.

What are features?

A feature is a self-contained extension that adds typed methods or behavior to a host object via .with(). The host starts with a base API, and each .with(feature()) call extends it by adding methods, validating dependencies, and narrowing the TypeScript type. See feature-core for the underlying primitives.

Why do libraries use a .with() chain instead of a declarative feature array?

The .with() chain (powered by feature-core) gives TypeScript inference per step. Each call narrows the type based on what was installed before it.

const $count = createState(0).with(undoFeature());

$count.undo(); // typed
$count.missing(); // type error

A declarative feature array like features: [featureA(), featureB()] cannot validate dependencies or accumulate types left-to-right as reliably.

Why objects instead of classes?

This Medium post explains the key differences well.

Objects compose cleanly with the .with() model. Classes make that style of extension harder to type and harder to reuse across packages.