npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@obinexusltd/obix

v0.5.0

Published

OBIX Heart/Soul UI/UX SDK - Data-oriented, accessibility-first software development kit

Readme

obix

Previous name: @obinexusltd/obix — OBIX packages are named without an npm scope since decision D-102 (2026-09-29); the package, its version and its exports are unchanged.

The OBIX Heart/Soul UI/UX SDK umbrella package: one import for OBIX's reactivity and native browser runtime, the core runtime, the accessible UI primitives and the sub-systems.

npm install obix
import { ref, computed, watch, createObixApp } from "obix";

const count = ref(0);
const doubled = computed(() => count.value * 2);
watch(() => doubled.value, (now, before) => console.log(`doubled: ${before} → ${now}`));
count.value = 1; // after the next tick: "doubled: 0 → 2"

// a component compiled to canonical IR (see "Components" below) runs on OBIX's native runtime — no Vue, no React
createObixApp(counterIr).mount("#app");

and the component library, with the same single import:

import { createButton, ObixRuntime, Router, Forms, State } from "obix";

Components: author .obix, compile at build time, run with createObixApp

An OBIX component is written as an .obix file and uses the same names:

<script setup lang="ts">
import { ref, computed, watch } from "obix";
const count = ref(0);
const doubled = computed(() => count.value * 2);
</script>
<template>
  <button type="button" @click="count++">{{ count }} / {{ doubled }}</button>
</template>

Compiling it is a build-time step (the obix-compiler-* packages turn it into canonical DOP IR, obix-dop-ir/3); the compiler is never a dependency of obix and never part of an application's run time. createObixApp(ir) from obix runs the result. In an .obix file, watch lowers where the IR can represent it — a ref or a getter as the source and a callback of steps; its options, several sources and the stop handle are reported as deferred, never compiled halfway. In plain JavaScript, watch takes a getter: watch(() => count.value, callback).

What the root exports

| Line of the original barrel | Now resolves to | Shape | |---|---|---| | native runtime (D-104) | obix-runtime-reactivity, obix-runtime-browser | ref, computed, watch, isRef, batch, nextTick, createObixApp, ObixRuntimeError and their types — the runtime's own functions, not copies; its internals stay in obix-runtime-* |

| Line of the original barrel | Now resolves to | Shape | |---|---|---| | export * core | obix-core-runtime | ObixRuntime, StateHaltEngine, PolicyEngine, LifecycleHook, runtime types | | export * components | obix-core-component | component factories, FUD policies, design tokens, adapter helpers | | Router | obix-core-router | namespace | | Forms | obix-core-forms | namespace | | Accessibility | obix-core-a11y | namespace | | Telemetry | obix-core-telemetry | namespace | | State | obix-core-state | namespace | | Adapter | obix-binding-adapter | namespace | | Motion | obix-core-motion | namespace | | CLI | obix-config-schema | namespace, types only (see below) |

Differences from the original barrel (all recorded in docs/recovery/source-decisions.md)

  • PolicyResult. The core runtime and the components both declare a PolicyResult type with different shapes. Two export * of one name is a compile error, so the original barrel could not build. The runtime's PolicyResult keeps the name; the component one is exported as ComponentPolicyResult. (D-23)
  • CLI is types only. The CLI namespace carries the CLI's configuration contracts (CLIConfig, BuildConfig, BuildTarget, HotSwapConfig, CompileConfig, BuildResult, SemanticVersionX, SchemaValidation, CLICommand, CLIStatus, CLIState). The CLI itself — createCLI, compileFile, ComponentRegistry, the obix command — needs Node built-ins and the TypeScript compiler, so it must not be part of an entry point that browsers import: use obix-cli-build. (D-24)
  • The native runtime (added, D-104). The original barrel had no reactivity of its own; the umbrella now re-exports the public API of OBIX's native runtime, so that npm install obix is enough to write reactive code and to run compiled components. Additive: every name of the original barrel is still exported.
  • Dependencies. Only what the barrel imports is a dependency. The original manifest also listed ten drivers and ten language bindings that the barrel never imported; the documentation says they are "imported individually by target platform", so they are separate installs (obix-driver-*, obix-binding-*).

Provenance: export list from upstream:obix@82b96d0 (src/index.ts); package authored in the recovery. See PROVENANCE.json.

Installation

npm install obix

API surface

  • obix — 85 value exports: Accessibility, Adapter, CLI, DEFAULT_FOCUS_CONFIG, DEFAULT_JFIX_STRATEGY, DEFAULT_REDUCED_MOTION, DEFAULT_TOUCH_TARGET, Forms, JFIX_CLASS_MAP, JFIX_STRATEGIES, LifecycleHook, Motion, OBIX_MIN_TARGET_PX, ObixRuntime, ObixRuntimeError, PolicyEngine, PolicyViolationError, Router, State, StateHaltEngine, TOKENS, Telemetry, applyAccessibilityPolicy, applyAllFudPolicies, applyFocusPolicy, applyLoadingPolicy, applyReducedMotionPolicy, applyTouchTargetPolicy, batch, computed, createAccordion, createAlert, createAutocomplete, createBreadcrumb, createButton, createCard, createCheckbox, createDatePicker, createDropdown, createFileUpload, … (45 more)
  • Type declarations: ./dist/index.d.ts (and a declaration next to every JS entry point).

Architecture role

obix is the umbrella — the public entry point of OBIX (npm install obix). It re-exports the stable public API of the packages it depends on; applications start here.

The architecture of OBIX — the package families and which packages are public API — is indexed in the umbrella: docs/architecture.md.

Package relationships

Testing

  • 2 test files ship in the npm package (test/): the evidence of the package's contract, published so that its verification can be inspected — not runtime code (no entry point reaches them).
  • Standalone: 2 of 2 — they read nothing outside the package.
  • Run them with npm test (node --test "test/*.test.mjs") in the OBIX monorepo, which provides the test tooling (Node's test runner, TypeScript) and the harness.

Documentation

Repository

  • https://github.com/obinexus/obix — [email protected]:obinexus/obix.git
  • Issues: https://github.com/obinexus/obix/issues
  • The repository is a clean export of the package from the OBIX monorepo. Its lineage — the sources it was recovered from and its earlier names — is PROVENANCE.json, shipped in this package; the repository's copy also records the monorepo commit it was exported from.

License

MIT — see LICENSE.