Compatibility and verification

Last verified: 2026-08-10. Compatibility is evidence for the exact matrix below, not a claim about latest or every Storybook/shadcn project.

Status vocabulary

Compify uses narrow terms so static analysis is not confused with runtime proof:

A story marked portable in the retained v1/v2 wire contracts means only that its supported static args and component graph passed Compify diagnostics. It does not mean decorators, loaders, play functions, preview configuration, globals, providers, assets, aliases, rendering, behavior, or appearance were reproduced. The wording will be narrowed in the next schema revision.

Release-candidate matrix

These version labels identify the tested source checkout, not release status. The repository's v0.1.0 GitHub source tag already contains a CLI 0.2.0 manifest, while npm independently serves an older @compify/cli@0.1.0 from different source history. They are distinct historical artifacts. The current CLI 0.3.0 and addon 0.2.0 manifests below are unpublished AGPL candidates.

The consumer smoke fixture lives at examples/consumer-next-ts; synthetic sources live at examples/storybook-button and CLI test fixtures. The qualified external source and its exact license/provenance hashes live at examples/external-react-uswds-button. CI copies that fixture outside the Compify Git checkout before inspection so provenance is not misattributed to the enclosing repository. CI pins the shadcn version instead of using latest. Adding a version or upstream selection to this table requires a committed, licensed, checksummed fixture and a passing install/build gate.

Supported source shape today

The highest-confidence input is a single React package with:

• a classic CSF2/CSF3 file and explicit default meta.component bound to a dot-relative component import;
• an optional exact named export selected with --story;
• component implementation using static dot-relative text imports/re-exports, or exact in-package aliases accepted from a non-inherited tsconfig.json baseUrl/paths or unconditional string package.json#imports entry;
• npm runtime imports declared in the nearest package.json; and
• text source/style/JSON/SVG files inside that package, including quoted CSS/Sass/Less import/use/forward and CSS Modules composition edges, below documented limits.

Use --component-entry when component inference is the only missing link. Review every diagnostic and generated file. The selected story module itself is not installed; the artifact contains the component graph plus supported static story metadata.

Explicitly unsupported or unproven

• CSF Next .extend, Story.input/composed, computed/imported factory configuration and MDX stories. The basic imported preview.meta({ component }) plus meta.story({ static args }) form has synthetic static-parser coverage but not yet a Storybook runtime fixture;
• named cross-file story re-export catalogs such as export { X as Y } from …; local export-list aliases are supported;
• wildcard/fallback/inherited tsconfig aliases, conditional or wildcard package.json#imports, Vite/Webpack-only aliases, workspace source imports, Yarn PnP and conditional package exports; accepted exact aliases are rewritten to deterministic consumer-usable relative imports;
• local source outside the nearest package root or workspace:* distribution;
• arbitrary render, decorators, loaders, play functions, globals, preview providers/styles, or story-only imports;
• CSS url() asset closure, binary images/fonts/WASM and executable style configuration; quoted static stylesheet module edges are supported;
• automatic registryDependencies, arbitrary file targets, nonstandard consumer aliases, monorepo routing or dependency-range compatibility. Conventional component, lib, hook, and components/ui paths receive native shadcn file types and are exercised by the clean-consumer gate;
• Vite, Remix, JavaScript-only, Tailwind-version, Windows/case, authenticated transitive registry-dependency chains, repeat-add merge behavior, runtime, accessibility or visual fidelity until fixtures are added. Same-domain v2 republishing and immutable digest-addressed revision retrieval are API-tested, but are not a claim about consumer-side merge/update semantics.

The pre-alias resolver baseline analysis of Carbon, Chakra, Radix Primitives, Storybook Design System and Primer found that roughly 29% of 701 live story files matched the then-default mechanical boundary; selecting a named static story raised that to roughly 34%. The bounded alias work has not yet been rerun across that corpus, so those figures are historical baseline evidence, not current acceptance measurements. These are research estimates, not benchmark guarantees. Modern re-export/alias/workspace catalogs approached zero without architectural changes, while conventional colocated single-package stories were materially better. This is why the unreleased 0.2.0 source candidate is a narrow pilot, not a released or general Storybook conversion claim.

Representative upstream shapes:

• Carbon Button story
• Chakra re-export story
• Radix Storybook workspace story
• Storybook Design System Button
• Primer Button story

Adding compatibility

A qualified fixture must prove a repeated user pattern, not merely increase a support count. Add static graph assertions, exact diagnostics, direct registry JSON review, pinned shadcn view/add, expected target mapping, typecheck and production build. Preserve failures as regression fixtures. Runtime/visual verification, if required, must be a separate sandboxed phase because executing Storybook or consumer code is outside the static-inspection security boundary.