Javascript products

The Open Source Front / Attio meets N8N Alternative. Learn more » Website · Issues An open-source AI-powered email support ticket service for Shopify businesses. Integrates with Gmail and Outlook to provide automated customer support with workflow automation. Features AI-powered automated response generation (OpenAI, Anthropic, Google, Groq) Gmail & Outlook email integration Shopify integration for customer context Workflow automation engine Knowledge base for AI context Real-time notifications Multi-tenant organization support Comprehensive ticket management Advanced filtering and searching Screenshots Tech Stack Framework: Next.js 16.1 with React Server Components API: tRPC v11 with React Query Database: PostgreSQL with Drizzle ORM UI: TailwindCSS v4 with shadcn/ui components Forms: React Hook Form with Zod validation Caching: Redis Build: Turborepo Real-time: Pusher Deployment: SST (AWS) / Docker / Railway Package Manager: pnpm Prerequisites Node.js 22 or later pnpm 10.17 or later PostgreSQL database Redis Quick Start 1-Click Docker Setup (Recommended) Run a single command to install and start Auxx.ai: bash <(curl -sL https://raw.githubusercontent.com/Auxx-Ai/auxx-ai/main/docker/scripts/install.sh) The install script automatically: Checks dependencies (Docker, Docker Compose v2, curl, openssl) Downloads docker-compose.yml and .env.example Generates all secrets (database password, Redis password, auth secret, Ed25519 keypair, etc.) Detects port conflicts and prompts for alternatives Starts all containers and waits for health checks Opens the app in your browser Pin a specific version: VERSION=0.1.64 bash <(curl -sL https://raw.githubusercontent.com/Auxx-Ai/auxx-ai/main/docker/scripts/install.sh) Once running, visit http://localhost:3000 and follow the setup wizard. First-time Setup When you first run the application, you'll be guided through a setup wizard to: Create a super admin account Configure your organization details Set up initial settings Environment Variables Category Variables Database DATABASE_URL Redis REDIS_HOST, REDIS_PORT, REDIS_PASSWORD Auth AUTH_GOOGLE_*, AUTH_GITHUB_* Gmail GOOGLE_CLIENT_*, GOOGLE_PUBSUB_* Outlook OUTLOOK_CLIENT_*, OUTLOOK_WEBHOOK_* Shopify SHOPIFY_API_KEY, SHOPIFY_API_SECRET AI Models OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY, GROQ_API_KEY Email Provider EMAIL_PROVIDER, MAILGUN_* or SMTP_* Storage S3_BUCKET, S3_REGION, S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY Payments STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET Real-time PUSHER_* See individual .env.example files for complete configuration options. Project Structure ├── apps/ │ ├── web/ # Main Next.js application │ ├── api/ # API server │ ├── worker/ # Background job processor │ ├── kb/ # Knowledge base app │ ├── lambda/ # AWS Lambda functions │ ├── docs/ # Documentation site │ ├── homepage/ # Marketing site │ └── build/ # Build utilities │ ├── packages/ │ ├── database/ # Drizzle ORM schema & migrations │ ├── ui/ # Shared UI components (shadcn) │ ├── lib/ # Shared utilities │ ├── config/ # Shared configuration │ ├── services/ # Business logic services │ ├── sdk/ # Auxx SDK │ ├── email/ # Email handling │ ├── redis/ # Redis client │ ├── credentials/ # Credentials management │ ├── billing/ # Stripe billing │ ├── workflow-nodes/ # Workflow automation nodes │ ├── logger/ # Logging utilities │ ├── seed/ # Database seeding │ ├── eslint-config/ # Shared ESLint config │ └── typescript-config/# Shared TypeScript config │ ├── infra/ # Infrastructure configs ├── scripts/ # Utility scripts └── docs/ # Additional documentation Development Common Commands # Start all apps in development mode pnpm dev # Build all packages pnpm build # Lint and format pnpm lint pnpm lint:fix pnpm format # Run tests pnpm test pnpm test:ui # With Vitest UI pnpm test:coverage # With coverage report Database Commands (Drizzle) # Generate migrations after schema changes pnpm db:generate # Run migrations pnpm db:migrate # Open Drizzle Studio (database GUI) pnpm db:studio # Reset database pnpm db:reset # Seed database pnpm seed pnpm seed:dev # Development seed pnpm seed:test # Test data seed Contributing Contributions are welcome! Please feel free to submit a Pull Request. Fork the repository Create your feature branch (git checkout -b feature/amazing-feature) Commit your changes (git commit -m 'Add some amazing feature') Push to the branch (git push origin feature/amazing-feature) Open a Pull Request Support If you encounter any problems or have questions, please open an issue on GitHub.

AlphaClaw The ultimate OpenClaw harness. Deploy in minutes. Stay running for months. Observability. Reliability. Agent discipline. Zero SSH rescue missions. AlphaClaw wraps OpenClaw with a convenient setup wizard, self-healing watchdog, Git-backed rollback, and full browser-based observability. Ships with anti-drift prompt hardening to keep your agent disciplined, and simplifies integrations (e.g. Google Workspace, Google Pub/Sub, Telegram Topics, Slack, Discord) so you can manage multiple agents from one UI instead of config files. First deploy to first message in under five minutes. Render sponsors AlphaClaw. Redeem $50 in Render credits with code RENDER-ALPHACLAW. Platform: AlphaClaw currently targets Docker/Linux deployments. macOS local development is not yet supported. Features Setup UI: Password-protected web dashboard for onboarding, configuration, and day-to-day management. Guided Onboarding: Step-by-step setup wizard — model selection, provider credentials, GitHub repo, channel pairing. Multi-Agent Management: Sidebar-driven agent navigation with create, rename, and delete flows. Per-agent overview cards, channel bindings, and URL-driven agent selection. Gateway Manager: Spawns, monitors, restarts, and proxies the OpenClaw gateway as a managed child process. Watchdog: Crash detection, crash-loop recovery, auto-repair (openclaw doctor --fix), Telegram/Discord/Slack notifications, and a live interactive terminal for monitoring gateway output directly from the browser. Channel Orchestration: Telegram, Discord, and Slack bot pairing with per-agent channel bindings, credential sync, and a guided wizard for splitting Telegram into multi-threaded topic groups as your usage grows. Google Workspace: OAuth integration for Gmail, Calendar, Drive, Docs, Sheets, Tasks, Contacts, and Meet, plus guided Gmail watch setup with Google Pub/Sub topic, subscription, and push endpoint handling. Cron Jobs: Dedicated cron tab with job management, an interactive rolling calendar, run-history drilldowns, trend analytics, and per-run usage breakdowns. Nodes: Guided local-node setup for VPS deployments with per-node browser attach checks, reconnect commands, and routing/pairing controls. Webhooks: Named webhook endpoints with per-hook transform modules, request logging, payload inspection, editable delivery destinations, and OAuth callback support for third-party auth flows. File Explorer: Browser-based workspace explorer with file visibility, inline edits, diff view, and Git-aware sync for quick fixes without SSH. Prompt Hardening: Ships anti-drift bootstrap prompts (AGENTS.md, TOOLS.md) injected into your agent's system prompt on every message — enforcing safe practices, commit discipline, and change summaries out of the box. Git Sync: Automatic hourly commits of your OpenClaw workspace to GitHub with configurable cron schedule. Combined with prompt hardening, every agent action is version-controlled and auditable. Version Management: In-place updates for both AlphaClaw and OpenClaw with in-app release notes, changelog review, and one-click apply. Codex OAuth: Built-in PKCE flow for OpenAI Codex CLI model access. Why AlphaClaw Zero to production in one deploy: Render/Railway templates ship a complete stack — no manual gateway setup. Self-healing: Watchdog detects crashes, enters repair mode, relaunches the gateway, and notifies you. Everything in the browser: No SSH, no config files to hand-edit, no CLI required after first deploy. Stays out of the way: AlphaClaw manages infrastructure; OpenClaw handles the AI. No Lock-in. Eject Anytime. AlphaClaw simply wraps OpenClaw, it's not a dependency. Remove AlphaClaw and your agent keeps running. Nothing proprietary, nothing to migrate. Quick Start Deploy on Render (recommended) Render sponsors AlphaClaw. Use code RENDER-ALPHACLAW to redeem $50 in Render credits. The deployment is maintained in Render's official AlphaClaw template repository. Other deployment options Set SETUP_PASSWORD at deploy time and visit your deployment URL. The welcome wizard handles the rest. Railway users: after deploying, upgrade to the Hobby plan and redeploy to ensure your service has at least 8 GB of RAM. The Trial plan's memory limit can cause out-of-memory crashes during normal operation. Local / Docker npm install @chrysb/alphaclaw npx alphaclaw start Or with Docker: FROM node:22-slim RUN apt-get update && apt-get install -y git curl procps cron tini && rm -rf /var/lib/apt/lists/* WORKDIR /app COPY package.json ./ RUN npm install --omit=dev ENV PATH="/app/node_modules/.bin:$PATH" ENV ALPHACLAW_ROOT_DIR=/data EXPOSE 3000 ENTRYPOINT ["/usr/bin/tini", "--"] CMD ["alphaclaw", "start"] Setup UI Tab What it manages General Gateway status, channel health, pending pairings, Google Workspace, repo sync schedule, OpenClaw dashboard Browse File explorer for workspace visibility, inline edits, diff review, and Git-backed sync Usage Token summaries, per-session and per-agent cost and token breakdown with source/agent dimension comparisons Cron Cron job management, interactive rolling calendar, run-history drilldowns, trend analytics, and per-run usage breakdowns Nodes Guided local-node setup for VPS deployments, per-node browser attach, reconnect commands, and routing/pairing controls Watchdog Health monitoring, crash-loop status, auto-repair toggle, notifications, event log, live log tail, interactive terminal Providers AI provider credentials (Anthropic, OpenAI, Gemini, Mistral, Voyage, Groq, Deepgram) and model selection Envars Environment variables — view, edit, add — with gateway restart prompts Webhooks Webhook endpoints, transform modules, request history, payload inspection, OAuth callbacks, Gmail watch delivery flows CLI Command Description alphaclaw start Start the server (Setup UI + gateway manager) alphaclaw git-sync -m "message" Commit and push the OpenClaw workspace alphaclaw telegram topic add --thread <id> --name <text> Register a Telegram topic mapping alphaclaw version Print version alphaclaw help Show help Architecture graph TD subgraph AlphaClaw UI["Setup UI<br/><small>Preact + htm + Wouter</small>"] WD["Watchdog<br/><small>Crash recovery · Notifications</small>"] WH["Webhooks<br/><small>Transforms · Request logging</small>"] UI --> API WD --> API WH --> API API["Express Server<br/><small>JSON APIs · Auth · Proxy</small>"] end API -- "proxy" --> GW["OpenClaw Gateway<br/><small>Child process · 127.0.0.1:18789</small>"] GW --> DATA["ALPHACLAW_ROOT_DIR<br/><small>.openclaw/ · .env · logs · SQLite</small>"] Loading Watchdog The built-in watchdog monitors gateway health and recovers from failures automatically. Capability Details Health checks Periodic openclaw health with configurable interval Crash detection Listens for gateway exit events Crash-loop detection Threshold-based (default: 3 crashes in 300s) Auto-repair Runs openclaw doctor --fix --yes, relaunches gateway Notifications Telegram, Discord, and Slack alerts for crashes, repairs, and recovery Event log SQLite-backed incident history with API and UI access Environment Variables Variable Required Description SETUP_PASSWORD Yes Password for the Setup UI OPENCLAW_GATEWAY_TOKEN Auto Gateway auth token (auto-generated if unset) GITHUB_TOKEN Yes GitHub PAT for workspace repo GITHUB_WORKSPACE_REPO Yes GitHub repo for workspace sync (e.g. owner/repo) TELEGRAM_BOT_TOKEN Optional Telegram bot token DISCORD_BOT_TOKEN Optional Discord bot token SLACK_BOT_TOKEN Optional Slack bot token (Socket Mode) WATCHDOG_AUTO_REPAIR Optional Enable auto-repair on crash (true/false) WATCHDOG_NOTIFICATIONS_DISABLED Optional Disable watchdog notifications (true/false) PORT Optional Server port (default 3000) ALPHACLAW_ROOT_DIR Optional Data directory (default /data) ALPHACLAW_SKIP_SYSTEM_CRON_INSTALL Optional Skip writes to /etc/cron.d while keeping cron config (true/false); the managed hourly script still exits when sync is disabled ALPHACLAW_GIT_SHIM_PATH Optional Install the managed git auth shim at this path and prepend its directory to runtime PATH (default /usr/local/bin/git) ALPHACLAW_GIT_ASKPASS_PATH Optional Install the git askpass helper at this path (default $TMPDIR/alphaclaw-git-askpass.sh) TRUST_PROXY_HOPS Optional Trust proxy hop count for correct client IP REMOTE_MCP_URL Optional Upstream remote MCP server URL. When set together with REMOTE_MCP_API_TOKEN, AlphaClaw writes a managed mcp.servers.<name> entry to openclaw.json on every gateway start. REMOTE_MCP_API_TOKEN Optional Bearer token for the remote MCP server. Persisted in openclaw.json as the ${REMOTE_MCP_API_TOKEN} reference, never as plaintext. REMOTE_MCP_NAME Optional Key under mcp.servers.<name>. Defaults to remote. Set it to label the entry (e.g. sure, notion). REMOTE_MCP_PROXY_URL Optional When set, OpenClaw connects here instead of REMOTE_MCP_URL. Intended for a same-host scanning proxy (e.g. pipelock mcp proxy --listen <REMOTE_MCP_PROXY_URL> --upstream <REMOTE_MCP_URL>). Implementation is proxy-agnostic. OpenAI-compatible /v1 proxy AlphaClaw can expose an OpenAI-compatible API surface on the same public port as the Setup UI. It is disabled by default. Enable it from the Setup UI under General -> Features -> API; the setting is persisted in alphaclaw.json in the OpenClaw repo so workspace sync can commit the change. Path Method Notes /v1/chat/completions POST Streams when stream: true. Use model: "openclaw/default" or openclaw/<agentId>. /v1/responses POST OpenClaw's /v1/responses surface (enabled together with chat completions). /v1/embeddings POST Routes to OpenClaw's embeddings endpoint. /v1/models, /v1/models/<id> GET Lists OpenClaw agent targets. When enabled, the proxy forwards requests to the loopback OpenClaw gateway. AlphaClaw requires Authorization: Bearer <OPENCLAW_GATEWAY_TOKEN> and rejects requests when the gateway token is missing or does not match before forwarding to OpenClaw. Failed bearer-token attempts are rate-limited before proxying. The setup-UI cookie is stripped before forwarding, hop-by-hop response headers are not passed through, and /v1 JSON request bodies are accepted up to 50 MB. When disabled or missing from alphaclaw.json, /v1 requests return 404. Security boundary (important). OpenClaw treats /v1/chat/completions as a full operator-access surface. A caller with a valid OPENCLAW_GATEWAY_TOKEN can run any tool the configured agent profile allows. Treat this token like an owner credential: Use this surface only for trusted server-to-server callers (for example, a self-hosted app that needs OpenClaw as its external assistant). Do not hand the gateway token to end-user clients. If your front door is public (Render, Fly, fly-style PaaS), make sure SETUP_PASSWORD is strong and that the gateway token is held by exactly one trusted backend. When REMOTE_MCP_URL + REMOTE_MCP_API_TOKEN are set, AlphaClaw also registers an mcp.servers.<REMOTE_MCP_NAME> block (default key remote) in openclaw.json so the agent can call back into that remote MCP server. Set REMOTE_MCP_PROXY_URL to route those callbacks through a same-host scanning proxy (for example a Pipelock MCP reverse proxy running in the same container).

alfama ⚡ Fine grained reactive UI Library. npm: npm i alfama cdn: https://cdn.jsdelivr.net/npm/alfama/+esm Features Rich and Complete: From support for SVG to popular patterns like dangerouslySetInnerHTML, ref to <Fragment> and <Portal /> alfama has you covered. Small: Fully featured at ~9kB gzip. Truly reactive and fine grained: Unlike VDOM libraries which use diffing to compute changes, it uses fine grained updates to target only the DOM which needs to update. No Magic: Explicit subscriptions obviate the need of sample/untrack methods found in other fine grained reactive libraries like solid/sinuous. Importantly, many feel that this also makes your code easy to reason about. Signals and Stores: Signals for primitives and Stores for deeply nested objects/arrays. First class HMR: Preserves Signals/Stores across HMR loads for a truly stable HMR experience. DevEx: no compile step needed if you want: choose your view syntax: h for plain javascript or <JSX/> for babel/typescript. Backers & Sponsors grati.co Next-Generation IDE Ecosystem alfama-router Router with a familiar react-router like API Example Counter - Codesandbox /** @jsx h **/ import { component, h, render } from "alfama"; // 1) The signal/wire/store functions are passed as a param to // component definition const Page = component("HomePage", (props, { signal, wire }) => { // 2) Named signals for stable HMR const [count, setCount] = signal("count", 0); // or $count = signal("count", 0) and then $count.get/$count.set // 3) Most importantly: wire reactivity to signals // with explicit subscription using the $ token param // NB: also makes code easy to reason about and prevents those pesky untrack/sample related errors const $doubleCount = wire(($) => count($) * 2); return ( <div id="home"> <p>Hey, {props.name}</p> <button onClick={() => setCount(count() + 1)}> Increment / {wire(count)}) </button> <p>Double count = {$doubleCount}</p> </div> ); }); render(<Page name="John Doe" />, document.body); Motivation This library is at its core inspired by haptic that in particular it also favours manual subscription model instead of automatic subscriptions model. This oblivates the need of sample/untrack found in almost all other reactive libraries. Also it borrows the nomenclature of aptly named Signal and Wire from haptic. It's also influenced by Sinuous, Solid, & S.js API Core signal: create a signal export const HomePage = component<{ name: string }>( "HomePage", (props, { signal, wire }) => { const [count, setCount] = signal("count", 0); //.. rest of component } ); wire: create a wire <div id="home"> <button onclick={() => { setCount(count() + 1); }} > Increment to {wire(($) => $(count))} </button> </div> store: create a store to hold object/arrays export const Todos = component("Todos", (props, { signal, wire, store }) => { const $todos = store("todos", { items: [{ task: "Do Something" }, { task: "Do Something else" }], }); return ( <ul> <Each cursor={$todos.items} renderItem={(cursor) => { return <li>{cursor().task}</li>; }} ></Each> </ul> ); }); defineContext: define context value export const RouterContext = defineContext<RouterObject>("RouterObject"); setContext: set context value const BrowserRouter = component("Router", (props, { setContext, signal }) => { setContext( RouterContext, signal("router", createRouter(window.history, window.location)) ); return props.children; }); getContext: get context value const Link = component("Link", (props: any, { signal, wire, getContext }) => { const router = getContext(RouterContext); //... rest of component }); onMount: triggered on mount export const Prosemirror = component("Prosemirror", (props, { onMount }) => { onMount(() => { console.log("component mounted"); }); // ... }); onUnmount: triggered on unmount export const Prosemirror = component("Prosemirror", (props, { onUnmount }) => { onUnmount(() => { console.log("component unmounted"); }); // ... }); Helper Components When: reactive if <When condition={($) => count($) > 5} views={{ true: () => { return <div key="true">"TRUE"</div>; }, false: () => { return <div key="false">"FALSE"</div>; }, }} ></When> Each: reactive map <Each cursor={$todos.items} renderItem={(cursor) => { return <li>{wire(cursor().task)}</li>; }} ></Each> Portal: mount outside of render tree export const PortalExample = component("PortalExample", (props, utils) => { const [active, setActive] = utils.signal("active", false); return ( <div> <button onClick={(e) => { setActive(!active()); }} > toggle modal </button> <When condition={($) => active($)} views={{ true: () => { return ( <Portal mount={document.body}> <div style="position: fixed; max-width: 400px; max-height: 50vh; background: white; padding: 7px; width: 100%; border: 1px solid #000;top: 0;"> <h1>Portal</h1> </div> </Portal> ); }, false: () => { return ""; }, }} ></When> </div> ); }); Reciepes HMR /** @jsx h **/ import { h, render } from "alfama"; import { Layout } from "./index"; const renderApp = ({ Layout }: { Layout: typeof Layout }) => render(<Layout />, document.getElementById("app")!); window.addEventListener("load", () => renderApp({ Layout })); if (import.meta.hot) { import.meta.hot.accept("./index", (newModule) => { if (newModule) renderApp(newModule as unknown as { Layout: typeof Layout }); }); } Refs /** @jsx h **/ export const Prosemirror = component("Prosemirror", (props, { onUnmount }) => { let container: Element | undefined = undefined; let prosemirror: EditorView | undefined = undefined; onUnmount(() => { if (prosemirror) { prosemirror.destroy(); } }); return ( <div style=" height: 100%; position: absolute; width: 100%;" ref={(el) => { container = el; if (container) { prosemirror = setupProsemirror(container); } }} ></div> ); }); dangerouslySetInnerHTML /** @jsx h **/ <div dangerouslySetInnerHTML={{ __html: `` }} /> Concepts Signals These are reactive read/write variables who notify subscribers when they've been written to. They act as dispatchers in the reactive system. const [count, setCount] = signal("count", 0); count(); // Passive read (read-pass) setCount(1); // Write // also possible to use get/set on signal instead of tuples const $count = signal("count", 0); $count.get(); $count.set(5); The subscribers to signals are wires, which will be introduced later. They subscribe by read-subscribing the signal. Stores Stores are for storing nested arrays/objects and also act as dispatchers in the reactive system. And like signals, stores can also be read subsribed by wires. Outside of wires, they can be read via reify function. Writes can be done via produce function immer style. const val = { name: "Jane", friends: [{ id: "1", name: "John" }] }; const $profile = store("profile", val); // Passive read (read-pass) const friends = reify($profile.friends); console.log(friends.length); // Write produce($profile.friends, (friends) => { friends.push({ id: "2", name: "John Doe 2" }); }); Wires These are task runners who subscribe to signals/stores and react to writes. They hold a function (the task) and manage its subscriptions, nested wires, run count, and other metadata. The wire provides a $ token to the function call that, at your discretion as the developer, can use to read-subscribe to signals. wire(($) => { // Explicitly subscribe to count signal getter using the subtoken "$" const countValue = $(count); // also possible to subscribe to a stores using "$" subtoken const friendsCount = $($profile.friends); return countValue + friendsCount; });

Vibe Compiler (vibec) A self-compiling tool that transforms prompt stacks into code and tests using LLM generation. Overview vibec is a unique compiler that processes markdown-based prompt stacks to generate code, tests, and documentation. It can compile itself through a bootstrap process, evolving its own implementation (bin/vibec.js) across numbered stages. The tool supports both static (.md) and dynamic (.js) plugins, maintains staged outputs in output/stacks/ for Git history, and aggregates the latest runtime version in output/current/ using a "Last-Wins" merge strategy. Project Structure vibec/ ├── bin/ # Initial implementation │ ├── vibec.js # Core compiler script │ └── test.sh # Test runner ├── bootstrap/ # Bootstrap documentation ├── stacks/ # Prompt stacks │ ├── core/ # Core functionality │ │ ├── 001_add_logging.md │ │ ├── 002_add_plugins.md │ │ ├── 003_add_cli.md │ │ ├── 004_add_config.md │ │ ├── 005_add_iterations.md │ │ ├── 006_add_dynamic_plugins.md │ │ └── plugins/ # Core plugins │ └── tests/ # Test generation ├── output/ # Generated artifacts │ ├── bootstrap/ # Bootstrap outputs │ │ ├── bin/ # Bootstrap compiler │ │ │ └── vibec.js │ │ ├── bootstrap.js # Bootstrap script │ │ └── test.sh # Bootstrap test script │ ├── current/ # Latest merged runtime version │ │ ├── bin/ # Current compiler │ │ │ └── vibec.js │ │ ├── bootstrap.js # Current bootstrap script │ │ ├── test.js # Current test suite │ │ └── test.sh # Current test script │ └── stacks/ # Staged stack outputs │ ├── core/ # Core stack stages │ │ ├── 001_add_logging/ │ │ │ └── bin/ │ │ │ └── vibec.js │ │ ├── 002_add_plugins/ │ │ │ └── bin/ │ │ │ └── vibec.js │ │ ├── 003_add_cli/ │ │ │ └── bin/ │ │ │ └── vibec.js │ │ ├── 004_add_config/ │ │ │ └── bin/ │ │ │ └── vibec.js │ │ ├── 005_add_iterations/ │ │ │ └── bin/ │ │ │ └── vibec.js │ │ ├── 006_add_dynamic_plugins/ │ │ │ └── bin/ │ │ │ └── vibec.js │ └── tests/ # Test stack stages │ ├── 001_basic_tests/ │ │ ├── test.js │ │ └── test.sh │ ├── 002_feature_tests/ │ │ └── test.js │ ├── 003_cli_tests/ │ │ └── test.js │ └── 004_config_tests/ │ └── test.js ├── vibec.json # Configuration file └── package.json # Node dependencies Architecture vibec employs a progressive bootstrapping process: Begins with the initial bin/vibec.js implementation Processes numbered stages sequentially (001, 002, etc.) Updates vibec.js when generated in a stage, using the new version for subsequent stages Creates a self-improving cycle where the compiler evolves during compilation Getting Started Installation Install globally: npm install -g vibec Or use via npx: npx vibec --version Set your LLM API key: export VIBEC_API_KEY=your_api_key_here Usage Run with custom options: npx vibec --stacks=core,tests --test-cmd="npm test" --retries=2 --iterations=3 --output=output CLI options: --workdir=<dir>: Working directory (default: .) --stacks=<stack1,stack2,...>: Stacks to process (default: core) --dry-run: Simulate without modifications (default: false) --start=<number>: Start with specific stage number (default: none) --end=<number>: End with specific stage number (default: none) --api-url=<url>: LLM API endpoint (default: https://openrouter.ai/api/v1) --api-model=<model>: LLM model (default: anthropic/claude-3.7-sonnet) --test-cmd=<command>: Test command to run (default: none) --retries=<number>: Retry attempts for API calls (≥ 0, default: 0) --iterations=<number>: Number of times to retry a stage on test failure (> 0, default: 2) --plugin-timeout=<ms>: Timeout for JS plugins in milliseconds (default: 5000) --output=<dir>: Output directory (default: output) --help: Display usage information --version: Show version (e.g., vibec v1.0.0) Configuration Configure via vibec.json: { "workdir": ".", "stacks": ["core", "tests"], "dryRun": false, "start": null, "end": null, "testCmd": "npm test", "retries": 2, "iterations": 3, "pluginTimeout": 5000, "apiUrl": "https://openrouter.ai/api/v1", "apiModel": "anthropic/claude-3.7-sonnet", "output": "output" } Option precedence: CLI > Environment Variables > vibec.json > Defaults Validation: retries: Must be non-negative (≥ 0) iterations: Must be positive (> 0) pluginTimeout: Must be positive (> 0) Malformed JSON in vibec.json triggers an error log and falls back to defaults Environment Variables VIBEC_WORKDIR: Working directory path. VIBEC_STACKS: Comma-separated stacks (e.g., core,tests) VIBEC_DRY_RUN: true/false. VIBEC_START: Numeric stage value. VIBEC_END: Numeric stage value. VIBEC_OUTPUT: Output directory. VIBEC_TEST_CMD: Test command VIBEC_RETRIES: Retry count for API calls VIBEC_ITERATIONS: Number of times to retry a stage on test failure VIBEC_PLUGIN_TIMEOUT: Plugin timeout (ms) VIBEC_API_URL: LLM API endpoint VIBEC_API_KEY: LLM API key (recommended over config) VIBEC_API_MODEL: LLM model VIBEC_DEBUG: Enable debug logging (1 to enable) LLM Integration Compatible with OpenAI-style APIs. Configure via VIBEC_API_URL and VIBEC_API_KEY. Prompt Structure Prompts use markdown: # Component Name Description of the generation task. ## Context: file1.js, file2.js ## Output: path/to/output.js ## Context:: Reference files for context ## Output:: Specify output file paths (multiple allowed) Plugin System Static Plugins (.md) Stored in stacks/<stack>/plugins/ Appended to prompts in alphabetical order Used for adding reusable context or constraints to prompts Dynamic Plugins (.js) JavaScript modules in stacks/<stack>/plugins/ Executed as async functions in alphabetical order with configurable timeout Receive a context object with access to: { config, // vibec.json contents stack, // Current stack name promptNumber, // Current prompt number promptContent, // Content of the current prompt workingDir, // Path to output/current testCmd, // Test command testResult // Test execution result } Plugin errors are logged and skipped without halting execution Iteration System The iteration system allows automatic refinement of generated code: When a test fails, the test output is captured The prompt is re-run with test output included Process repeats up to iterations times (default: 2) If all iterations fail, the process exits with an error This enables self-healing code generation that can fix test failures automatically. Development Adding Prompts Create a new numbered file (e.g., stacks/core/005_new_feature.md) Use NNN_name.md naming convention Specify outputs with ## Output: Testing Tests in stacks/tests/ generate: test.sh: Validates vibec.js and runs test.js test.js: Uses tape for unit tests (Node builtins only) Tutorial: Building a Simple Pong Game This tutorial is based on a fully-functional example project available at: github.com/Strawberry-Computer/vibe-pong 1. Initialize Project mkdir pong-game && cd pong-game mkdir -p stacks/core/plugins output 2. Set Up Coding Style Plugin Create a coding style plugin that forces the LLM to mark its reasoning in the generated code. This clever trick helps us trace which parts of the prompt produced specific code: - Make it clear why any given code is written by adding a comment with relevant prompt snippet, like: ``` // PROMPT: <relevant prompt snippet> ``` - Don't use any other comments. 3. Define Initial Prompt # Pong Game Initial Setup Generate a simple Pong game using HTML, CSS, and JavaScript: - Use `<canvas width="800" height="400" id="pongCanvas">` - Draw a white paddle (10px wide, 100px high) at the left side of the canvas, movable up/down with arrow keys. - Draw a white ball (10px radius) starting at canvas center, moving diagonally with constant speed. - Bounce the ball off the top and side walls; reset to center if it hits the bottom (misses paddle). - Detect paddle collision to bounce the ball back up. - Use requestAnimationFrame for smooth animation. ## Output: index.html ## Output: styles.css ## Output: game.js 4. Configure { "stacks": ["core"], "output": "output" } 5. Compile export VIBEC_API_KEY=your_api_key_here npx vibec 6. Test cd output/current python3 -m http.server 8000 Visit http://localhost:8000. 7. Add Scoring # Add Scoring to Pong Enhance the Pong game by adding score display ## Context: index.html, game.js ## Output: index.html ## Output: game.js Run npx vibec again to update the game. 8. Add AI Player # Add AI Player to Pong Add the computer player which moves the paddle automatically. Make sure that at this point there are 2 paddles: one for the user and one for the computer. ## Context: index.html, game.js ## Output: game.js Run npx vibec one more time to complete the game with an AI opponent. 7. Debug Use VIBEC_DEBUG=1 npx vibec for detailed logs. Troubleshooting API Key Missing: Set VIBEC_API_KEY No Output: Verify ## Output: in prompts Command Not Found: Use npx vibec or install globally Test Failures: Check test output for details Plugin Timeout: Increase --plugin-timeout if needed

onnx-web-worker-starter A small starter for running ONNX Runtime Web inside a Web Worker. I pulled this pattern out after dealing with browser-side inference that was fine on desktop, then painful on mobile. Moving the model load and session.run() work into a worker keeps the UI thread free, and the app feels much less fragile while inference is running. This repo is just the reusable plumbing: public/onnx-worker/onnxWorker.js classic worker, loads ONNX Runtime src/lib/OnnxWorkerClient.js promise-based wrapper around postMessage src/hooks/useOnnxWorker.js optional React hook example/DemoComponent.jsx tiny usage example test/OnnxWorkerClient.test.js client protocol tests Bring your own model, inputs, preprocessing, and UI. Why the worker is in public The worker uses importScripts() to load ort.min.js, so it needs to be a classic worker with stable static URLs. I first tried the more obvious new URL("../worker/onnxWorker.js", import.meta.url) approach. It can work in some builds, but in Next.js it is easy to hit dev/prod differences: the worker may be emitted under a hashed URL, or dev tooling may inject code that a classic worker cannot parse. Serving the worker and ONNX Runtime files from public/onnx-worker/ is boring, but boring is exactly what I want here. Setup Install ONNX Runtime Web in your app: npm install onnxruntime-web Copy the worker and runtime files into your app's public folder: mkdir -p public/onnx-worker cp public/onnx-worker/onnxWorker.js your-app/public/onnx-worker/onnxWorker.js cp your-app/node_modules/onnxruntime-web/dist/ort.min.js your-app/public/onnx-worker/ort.min.js cp your-app/node_modules/onnxruntime-web/dist/*.wasm your-app/public/onnx-worker/ Put your model somewhere public too: public/models/my-model.onnx React example "use client"; import { useOnnxWorker } from "./src/hooks/useOnnxWorker.js"; export function MyInferenceButton() { const { status, progress, error, run } = useOnnxWorker({ modelUrl: "/models/my-model.onnx", workerUrl: "/onnx-worker/onnxWorker.js", runtimeUrl: "/onnx-worker/ort.min.js", wasmPaths: "/onnx-worker/", }); async function handleClick() { const outputs = await run({ input: { type: "float32", dims: [1, 3, 224, 224], data: new Float32Array(1 * 3 * 224 * 224), }, }); console.log(outputs); } return ( <button onClick={handleClick} disabled={status !== "ready"}> {status === "running" ? "Running..." : "Run inference"} {progress ? ` ${progress.percent}%` : ""} {error ? ` ${error}` : ""} </button> ); } Plain JS example import { OnnxWorkerClient } from "./src/lib/OnnxWorkerClient.js"; const client = new OnnxWorkerClient({ workerUrl: "/onnx-worker/onnxWorker.js", onProgress: (progress) => console.log(progress), }); await client.preload({ modelUrl: "/models/my-model.onnx", runtimeUrl: "/onnx-worker/ort.min.js", wasmPaths: "/onnx-worker/", }); const outputs = await client.run({ modelUrl: "/models/my-model.onnx", runtimeUrl: "/onnx-worker/ort.min.js", wasmPaths: "/onnx-worker/", inputs: { input: { type: "float32", dims: [1, 4], data: new Float32Array([1, 2, 3, 4]), }, }, }); Notes preload() loads ONNX Runtime and the model before the first run. run() sends tensor-like inputs to the worker and resolves serialized ONNX output tensors. dispose() terminates the worker and rejects pending requests. The worker serializes requests and keeps one cached session. requestTimeoutMs is optional. By default there is no timeout. Input tensors should match what ONNX Runtime expects: { type: "float32", dims: [1, 3, 224, 224], data: new Float32Array(...) } Tests npm test The tests cover the client/worker message protocol. You should still test with your real model in a browser, because ONNX Runtime's wasm files and execution providers can vary by version. Mobile note A worker keeps inference off the UI thread, but it does not magically make big models cheap. If you are working with images, crop and resize before inference when you can. That one change often matters more than any clever code. Origin This starter was extracted from production code while building Lumli. Lumli is a privacy-first browser-native AI studio where AI models run locally on your device.

tinyreplay tinyreplay is a small, self-hosted session replay tool. It records browser sessions with a browser SDK, stores replay batches in local SQLite, and shows them in a local dashboard. It is for indie developers and small teams that want to inspect what happened in a browser session without adopting a full analytics platform. tinyreplay is intentionally minimal. It does not provide funnels, heatmaps, feature flags, user profiles, accounts, billing, mobile SDKs, hosted storage, SSO, distributed ingestion, or compliance guarantees. tinyreplay is pre-1.0. The core local session replay flow works, but APIs, storage format, configuration, and dashboard behavior may change before v1. The v0.1.0 release should be treated as an early self-hosted release. Documentation: https://tinyreplay.hane.studio. Quick Start From a checkout: npm install npm run build npm run start Open http://localhost:3000. For development: npm install npm run dev npm run dev:docs The SDK runs in watch mode, the dashboard runs at http://localhost:3000, and the docs app runs at http://localhost:3001. Docker Run the published image (no checkout, no build): docker run -p 3000:3000 -v "$(pwd)/data:/app/data" ghcr.io/kzekiue/tinyreplay Open http://localhost:3000. Session data persists in ./data/tinyreplay.db on the host. The latest tag tracks main; tagged releases publish a versioned image (for example ghcr.io/kzekiue/tinyreplay:0.1.0). To build from source instead (for development or local changes): docker compose up --build The compose file mounts ./data to /app/data. The equivalent plain Docker commands: docker build -t tinyreplay . docker run --rm -p 3000:3000 -v "$(pwd)/data:/app/data" tinyreplay Useful endpoints: Purpose URL Dashboard http://localhost:3000 SDK bundle http://localhost:3000/sdk/tinyreplay.umd.js Ingest API POST http://localhost:3000/api/ingest Health probe GET http://localhost:3000/api/health SDK Setup Use the bundle served by your tinyreplay server: <script src="http://localhost:3000/sdk/tinyreplay.umd.js"></script> <script> TinyReplay.init({ endpoint: 'http://localhost:3000', projectId: 'my-project', }) </script> Or install the package after it is published: npm install @tinyreplay/sdk import { TinyReplay } from '@tinyreplay/sdk' TinyReplay.init({ endpoint: 'https://your-tinyreplay-instance.example', projectId: 'my-project', }) TinyReplay.init() is a no-op during server-side rendering and ignores repeated calls while a recorder is active. TinyReplay.stop() stops recording and flushes the current buffer. Example App The dependency-free example in examples/vanilla records clicks, input, scrolling, route changes, masking, and ignored elements. npm run build npm run start python3 -m http.server 4173 -d examples/vanilla Open http://localhost:4173, interact with the page, then open http://localhost:3000 and select the session. Storage tinyreplay stores data in SQLite through better-sqlite3. The server creates one database file: DATA_DIR/tinyreplay.db Local default: ./data/tinyreplay.db Docker default: /app/data/tinyreplay.db Replay event batches are stored as JSON in the events table and connected to rows in the sessions table. Retention is off by default. Set RETENTION_DAYS to delete older sessions during the hourly sweep. Privacy Defaults Masking happens in the browser before replay events are sent to the server. Defaults: Setting Behavior maskAllInputs Enabled by default for inputs, textareas, and selects. data-tr-mask Masks text inside the marked element and its children. data-tr-unmask Allows a specific non-sensitive input to be recorded. data-tr-ignore Blocks an element and its children from recording. The SDK records console messages and error messages for debugging. It records network metadata only: method, URL, status, and duration. It does not read request bodies, response bodies, request headers, response headers, cookies, or browser storage, except for its own session id in sessionStorage. Do not log secrets from the recorded app. Console capture records argument text. Configuration Copy .env.example to .env for local overrides. Variable Default Purpose PORT 3000 Server port. DATA_DIR ./data locally, /app/data in Docker SQLite directory. ALLOWED_ORIGINS * Comma-separated CORS allowlist for ingestion. DASHBOARD_PASSWORD unset Enables HTTP Basic auth for dashboard pages. INGEST_TOKEN unset Requires a token for POST /api/ingest. RETENTION_DAYS unset Deletes sessions older than this many days. RATE_LIMIT_PER_MIN 100 Ingest requests per minute per IP. MAX_PAYLOAD_BYTES 5000000 Maximum ingest request body size. Set DASHBOARD_PASSWORD, INGEST_TOKEN, and a narrow ALLOWED_ORIGINS value before exposing an instance outside a trusted network. Put TLS and stronger access control in front of tinyreplay with a reverse proxy. Development npm install npm run dev npm run check Common commands: Command Purpose npm run check Release check: format, lint, architecture, typecheck, forbidden content, secret scan, build, tests. npm run build Build the SDK, server, and docs app. npm run dev:docs Run the docs app on port 3001. npm run test Run SDK and server tests. npm run lint Run ESLint. npm run typecheck Run TypeScript checks. npm run clean Remove build and coverage output. See CONTRIBUTING.md for contribution rules and ARCHITECTURE.md for the current module boundaries. Security Report security issues privately. See SECURITY.md.

slack-debloat De-bloat the native Slack app on macOS with your own CSS and JS — like uBlock Origin + Tampermonkey, but for the desktop app. Slack's macOS app is Electron, i.e. a Chromium rendering the same web app as your browser — you just normally can't put extensions in it. slack-debloat launches Slack with its Chrome DevTools Protocol port open (localhost-only) and runs a tiny zero-dependency injector that pushes your custom.css / custom.js into every Slack window, keeps them across reloads, and live-reapplies within a second whenever you save. Hide the Activity tab, the huddle button, Slackbot, upsell banners — whatever annoys you. Before After Hidden rows collapse for real (no blank slots — see auto-reflow below), and you can restyle what stays: here Threads got promoted to 18px semibold. How it works Slack Debloat.app (Dock icon) LaunchAgent (login) │ │ └─ launches Slack with └─ inject.mjs polls localhost:9222, --remote-debugging-port=9222 attaches to every Slack window via CDP, (localhost only) injects custom.css + custom.js, re-injects on every file save No patching of Slack.app (it's code-signed; modifying it breaks Gatekeeper and Keychain). Slack updates itself normally. Requirements macOS, Slack desktop app in /Applications Node.js ≥ 22 (uses the built-in WebSocket client — no npm dependencies) Install git clone https://github.com/benri-ai/slack-debloat.git cd slack-debloat ./install.sh Then launch Slack via the new Slack Debloat app (it wears Slack's own icon) and put it in your Dock in place of Slack. That's it. The installer: seeds config.json / custom.css / custom.js from the .example files (your copies are gitignored), installs a LaunchAgent that keeps the injector running from login, builds /Applications/Slack Debloat.app. Try it without installing anything: ./slack-debloat.sh relaunches Slack with the debug port and runs the injector in your terminal (Ctrl-C to stop; Slack keeps running). A thin green line at the very top of the Slack window confirms injection is working (remove it in custom.css once you trust the setup). Usage config.json — the built-in options config.json (seeded from config.json.example on install) is a flat map of option keys to booleans. Flip a key to true, save, and the running Slack updates within a second — no restart, no rebuild. It's plain JSON on purpose: edit it by hand, or point your LLM at this README and let it do the flipping. { "hide-slackbot-dm": true, "hide-upsell-banners": true, "bigger-threads-row": true } (Keys you omit default to off; unknown keys are ignored with a warning in injector.log.) key what it does hide-slackbot-dm Slackbot DM row in the sidebar hide-threads-row Threads row in the sidebar hide-huddles-row Huddles row in the sidebar hide-drafts-row Drafts & sent row in the sidebar hide-directory-row Directory row in the sidebar hide-slack-connect-row External connections (Slack Connect) header in the sidebar hide-activity-tab Activity tab in the left rail (hides its badge too) hide-later-tab Later tab in the left rail hide-files-tab Files tab in the left rail hide-tools-tab Tools tab in the left rail hide-huddle-button Huddle button in the channel header hide-slackbot-ai-button Slackbot AI button next to the search bar hide-upsell-banners In-channel "megaphone" promo banners (Business+ trials etc.) bigger-threads-row Make the Threads sidebar row larger (18px semibold, bigger icon) The selectors behind these keys live in catalog.mjs, verified on Slack 4.50. Slack updates occasionally rename them; fixes are usually a two-minute DevTools job (see below) — PRs welcome. custom.css / custom.js — everything else Hide things by hand: for anything not in the catalog, edit custom.css, save — same ~1s live apply. The .example file ships with commented-out rules showing the patterns. Find selectors: while Slack runs debloated, open http://localhost:9222 in Chrome and you get full DevTools against the native app. Prefer Slack's [data-qa=...] attributes — they're much more stable than the generated class names. Sidebar rows are virtualized, so hide the whole row wrapper: [data-qa="virtual-list-item"]:has([data-qa^="channel_sidebar_pslackbot"]) { display: none !important; } Rows hidden this way don't leave blank slots: the injector ships an auto-reflow shim that detects hidden virtual-list rows and shifts the remaining rows up, re-applying whenever Slack re-renders. The sidebar collapses cleanly, as if the items never existed. Run scripts: custom.js runs in every Slack window on load and on every save (write idempotent code). Poke at the DOM from a terminal: node eval.mjs 'document.title' node screenshot.mjs slack.png # full window node screenshot.mjs sidebar.png '.p-channel_sidebar' # clipped to a selector FAQ What if I open the regular Slack app? You get stock Slack (no debug port), and the injector just idles. Clicking Slack Debloat quits and relaunches it with the port. Note that if Slack's own "Launch app on login" setting is on, it starts stock at every boot — turn it off and click the wrapper instead. Does this survive Slack updates? The mechanism, yes. Individual CSS selectors may need a tweak when Slack renames things — that's the DevTools-at-localhost:9222 workflow. Do huddles / calls / notifications still work? Yes — it's the unmodified Slack app; nothing is patched or proxied. Security note: the DevTools port is bound to localhost only, but while Slack runs this way, any local process could attach to it and read your Slack session. Fine on a personal machine; know the trade-off. Uninstall: ./uninstall.sh, then quit and reopen Slack normally. Disclaimer Not affiliated with or endorsed by Slack/Salesforce. Cosmetic use at your own risk.

javascript

Explore categories

How Product Visit works