Installation#

SignalX can be installed in several ways depending on your project setup.

Create a New Project#

The fastest way to get started is with our CLI:

pnpm create @sigx@latest my-app

npm create @sigx@latest my-app

yarn create @sigx@latest my-app

bun create @sigx@latest my-app

This will scaffold a new project with:

• Vite for development and building
• TypeScript configuration
• SignalX and the Vite plugin pre-configured

Add to Existing Project#

Using npm#

pnpm add sigx @sigx/vite

npm install sigx @sigx/vite

yarn add sigx @sigx/vite

bun add sigx @sigx/vite

Using pnpm#

pnpm add sigx @sigx/vite

npm install sigx @sigx/vite

yarn add sigx @sigx/vite

bun add sigx @sigx/vite

Using yarn#

pnpm add sigx @sigx/vite

npm install sigx @sigx/vite

yarn add sigx @sigx/vite

bun add sigx @sigx/vite

Apps install sigx; libraries peer on it#

sigx is the one package that brings @sigx/reactivity, @sigx/runtime-core and @sigx/runtime-dom into a project. Every other @sigx/* package — @sigx/vite, @sigx/cache, the server packs, @sigx/router, @sigx/store and the rest of the ecosystem — declares the core packages as peerDependencies (^1.0.0) and uses the copy your app installed. So an app installs sigx plus the packs it uses, and nothing else from core.

If you are publishing a library, do the same thing the ecosystem does: list sigx (web-only) or @sigx/reactivity + @sigx/runtime-core (renderer-neutral) under peerDependencies at ^1.0.0, never under dependencies. A page must load exactly one copy of the reactive core — a second copy throws in development. See Stability & versioning for the full table and the fix for a duplicate.

Configure Vite#

Add the SignalX plugin to your Vite configuration:

// vite.config.ts
import { defineConfig } from 'vite';
import { sigxPlugin } from '@sigx/vite';

export default defineConfig({
    plugins: [sigxPlugin()],
});

TypeScript Configuration#

For the best TypeScript experience, update your tsconfig.json:

{
    "compilerOptions": {
        "jsx": "preserve",
        "jsxImportSource": "sigx",
        "moduleResolution": "bundler"
    }
}

jsxImportSource: "sigx" is the setting for web apps: tags are typed by the DOM renderer's HTML and SVG table, so an unknown tag such as <blink> is a type error. A headless or non-web renderer built on @sigx/runtime-core alone uses "@sigx/runtime-core" and declares its own elements — see JSX setup per consumer kind.

Package Versions#

SignalX follows semantic versioning — from 1.0.0, breaking changes happen only at a major; Stability & versioning spells out what is covered. The versions below are pulled from npm at build time, so they track the current latest release without hand-editing (falling back to the last committed values if npm is unreachable):

Development and Production Builds#

Every SignalX package ships two builds:

• dist/*.js — the development build: dev warnings, the devtools integration, and runtime process.env.NODE_ENV checks.
• dist/*.prod.js — the production build: warnings and the devtools plumbing are compiled out.

Bundlers pick the right one automatically through the development / production export conditions — Vite needs no configuration. A vite build resolves the production build; vite dev resolves the development build. Resolvers that don't understand those conditions fall back to the development build, where a consumer-side NODE_ENV define still strips the dev branches — the same behavior as before.

For plain Node SSR (running the server renderer outside a bundler), opt into the stripped build with the production condition:

node --conditions=production server.js

There's nothing to configure in your app — devtools and dev-only warnings simply disappear from production output.

Next Steps#

• Quick Start - Build your first component
• Signals - Learn about reactive state
• Stability & versioning - What 1.0 promises, and upgrading from 0.15