Packages

Five npm packages sit alongside the copy-paste registry, for the jobs that copied source cannot do. None of them has shipped yet.

Overview

opsinjs distributes components by copying source, not by npm. The reasoning is in Registry and distribution. That model is right for components and wrong for three other things:

Algorithms. The colour engine is maths. You want one implementation, versioned, callable from a script, producing identical answers in your CI and on this site. Copying it into ten projects produces ten slightly different answers over time.
Build-time tooling. A Tailwind preset and a stylesheet are configuration, not application code; nobody wants to hand-merge them.
A conventional consumer. Some teams cannot take copied source at all, because of procurement rules, monorepo policy, or a genuine preference. A normal package should exist for them.

So there are five packages. All five are status: planned, none has been published, and this group documents them as specifications so that the API can be reviewed before it is built rather than after.

Specification only. Nothing is implemented

Planned

opsinjs-packages is described here so that its intent, its refusals and its accessibility bar can be reviewed before a line of it is written. Treat everything below as a proposal under review. Do not generate code against it.

Questions this component has to answer before it ships

Should @opsinjs/react ship the same components the registry copies, or a smaller stable subset?
Does @opsinjs/color version independently of the design system, or in lockstep with the tokens?
What is the deprecation contract for a package that a health product has taken a hard dependency on?

No tracking issue yet.Roadmap Propose a change to this specification

The five

Package	What it is	Why it is a package and not copied source
`@opsinjs/color`	OKLCH, APCA, WCAG 2.2, gamut mapping, `deriveTheme()`	Maths. One implementation, checkable in your CI
`@opsinjs/motion`	Spring solving, `linear()` generation, reduced-motion helpers	Same reason. Also generates token values
`@opsinjs/react`	The components, as a conventional dependency	For teams that cannot take copied source
`@opsinjs/preset`	The Tailwind theme layer as an importable preset	Build configuration, not application code
`@opsinjs/tailwind.css`	The stylesheet: token layer, variants, degradations	A file you import, not a file you own

Which of these do you need?

For most projects: none of them.

The registry gives you components and a theme with no dependency at all, and a project can go a long way on copied source plus a stylesheet, arguably all the way. Reach for a package when you have a specific reason.

You want the contrast check in CI

@opsinjs/color. This is the strongest case for any of them: a theme you have changed needs its own measurements, and a browser tab is not a CI job. See Validating your theme.

You are generating tokens

@opsinjs/color and @opsinjs/motion are the engines this repository uses to produce its own generated files. If you are running a fork, you are already using them; the package makes them usable outside it.

Your organisation cannot take vendored source

@opsinjs/react. Accept the trade knowingly: you gain a normal upgrade path and lose the ability to read and edit the component that renders a clinical result.

You have many apps and one theme

@opsinjs/preset and @opsinjs/tailwind.css. Copying a stylesheet into twelve applications is how twelve applications end up with eleven themes.

Versioning and stability

Two policies, stated now because a health product will ask before it depends on anything.

The engines version independently. @opsinjs/color and @opsinjs/motion are libraries with their own semantics. A design-system release does not imply an engine release.

A change to a measured output is a breaking change. If apca() returns a different number for the same input, that is major, even if the API is identical. That is because somebody's CI gate depends on the number, not on the signature. This is stricter than most libraries and it is the correct rule for something whose output is used as an accessibility claim.

The general policy is in Versioning policy; these two are the package-specific parts of it.

Verify it worked

Nothing has shipped, so the honest check is on the specification rather than on an installation. Three things to look for when reviewing these pages:

Every proposed API is marked as proposed

A fenced signature on these pages is a proposal that may change without a deprecation cycle. If you find one that reads as though it exists, that is a documentation bug worth reporting.

Nothing here duplicates the registry

A package that re-solves a problem the registry already solves is scope creep. Each of the five should have a one-sentence answer to "why not copied source", and it is in the table above.

The clinical invariants survive

No package may make it easier to mix the two colour axes, invent a fifth status level, or assert a threshold. If a proposed API would, say so before it is built.

Troubleshooting

npm install @opsinjs/color fails. Nothing is published. That is the current state, not a registry outage.

An assistant generated an import from one of these. It read a proposal as an API. See Rules for agents; this is exactly the failure the not-implemented markers exist to prevent.

I need the colour maths today. The implementations are in this repository under lib/color/, hand-written and dependency-free, and the repository is licensed for you to use them. The package is packaging, not capability.

@opsinjs/color is the one with the strongest case for existing.
Registry and distribution is the model these packages sit beside.
Roadmap says when any of this might be real.