stx-plugin registers only ./src/ui, so the four components in src/components (CodeBlock, Hero, Footer, Installation) are exported but cannot be rendered

@stacksjs/components exports four components that no consumer can render, because the plugin registers only one of the package's two component directories.

Code

packages/components/stx-plugin.ts:18:

components: './src/ui',

config.ts:536-539 resolves that to a single directory, and utils.ts:744-766 / 816-861 walk only that subtree.

But src/components/ is a sibling of src/ui/, not a child:

$ ls packages/components/src/components/
CodeBlock.stx
Footer.stx
Hero.stx
index.ts
Installation.stx

and src/index.ts:2-5 exports CodeBlock, Footer, Hero and Installation as part of the public surface. So they are documented and importable as symbols, and unresolvable as tags.

Repro

<CodeBlock code="const a = 1" language="ts" />

renders the component-not-found error string rather than the component. Same for <Hero>, <Footer>, <Installation>.

Impact

These are the four highest-level components in the package — the ones an app is most likely to reach for. Concretely, the app I hit this in has a hand-rolled install-snippet block (CSS, markup and a client script for the copy button) that <CodeBlock> exists to replace; the component is documented, exported, and cannot be invoked.

Fix

Register both directories:

components: ['./src/ui', './src/components'],

if the resolver accepts an array — config.ts:536-539 resolves a single dir today, so this may need the multi-dir path rather than just a config change. The alternative is moving src/components/* under src/ui/, which is a bigger change to the package's public layout but leaves one directory to register.

Worth a test that renders one tag from each exported component, which would have caught this and would catch the next component added outside the registered tree.

Related

• #1817 — <component :is> ordering; the other reason a chunk of this package does not render. Between the two, 30 of 91 primitives are currently unusable.

Fixed in 4e12377d5b.

Plugin components now accepts an array, and @stacksjs/components registers both roots. Widening the field rather than switching the path to ./src was deliberate: src/ also contains composables/ and utils/, and pointing the component resolver at the package root would have it walking TypeScript modules looking for .stx files.

Your observation that these are the four highest-level components in the package is what moved it up the list — <CodeBlock> in particular exists precisely to replace the hand-rolled install-snippet block you describe, so the failure mode was "reach for the obvious component, get an error string, hand-roll it instead".