@barefootjs/vite 0.30.0

package/dist/child-marker.d.ts

@@ -0,0 +1,62 @@
+/**
+ * `@bf-child:<Name>` marker resolution.
+ *
+ * The compiler emits `import '/* @bf-child:ChildName *\/'` inside a
+ * component's client JS for every OTHER component it references (loop-body
+ * children, `initChild`-driven nested components, etc.) — see
+ * `packages/jsx/src/ir-to-client-js/child-components.ts`. That specifier
+ * is not a real module: it's a marker this plugin must resolve at build
+ * time, one way or another, for every reference it stands for.
+ *
+ * Simply DROPPING the marker (resolving it to an empty no-op module) is
+ * not a safe choice for every child reference the marker stands for, only
+ * for SOME of them. The distinction (found empirically against gin's real
+ * TodoApp/TodoItem — no PR01-03 fixture exercised this shape):
+ *
+ * - A child rendered via `initChild()` (an SSR-hydrated child, or one
+ *   whose scope a cross-template Go/ERB/… render already put on the
+ *   page) is genuinely safe to drop: `@barefootjs/client`'s registry
+ *   (`packages/client/src/runtime/registry.ts`) queues an `initChild`
+ *   call for a not-yet-registered name (`pendingChildInits`) and drains
+ *   it the moment the child's OWN script loads and calls
+ *   `registerComponent` — however that script physically reached the
+ *   page. As long as the child's own template renders somewhere (which
+ *   is what registers its script — see `plugin.ts`'s docstring), this
+ *   is load-order-tolerant by design.
+ * - A child created via `createComponent(name, …)` for a PURELY
+ *   client-rendered loop (no server-side row template at all — e.g.
+ *   TodoApp's `.map()` over `initialTodos`, as opposed to TodoAppSSR's
+ *   server-rendered rows) is NOT tolerant: `materializeComponent`
+ *   (`packages/client/src/runtime/component.ts`) does one synchronous
+ *   `getTemplate(name)` registry lookup with NO queueing — if the
+ *   child's script hasn't run yet, it silently renders a placeholder
+ *   and NEVER retries. If nothing else on the page happens to reference
+ *   the child, ITS SCRIPT NEVER LOADS AT ALL, and the row permanently
+ *   fails to render.
+ *
+ * Resolving every marker to a REAL import of the named child's `.tsx`
+ * source (when discovered) closes this gap the same way Rollup already
+ * handles every other cross-module reference in this design: the
+ * bare `import '/* @bf-child:ChildName *\/'` statement's TEXT doesn't
+ * need to change, only what it resolves to. Once it resolves to
+ * `ChildName.tsx`, Rollup's OWN module graph puts an entry-to-entry
+ * static import in the output (the child is ALSO independently an entry
+ * point — every discovered `'use client'` file is), which is exactly
+ * what makes the browser fetch and execute the child's script as a side
+ * effect of loading the parent's — no registry timing dependent on
+ * anything server-side at all. A name that can't be resolved (unknown,
+ * or a multi-component-per-file export the simple name→file map below
+ * doesn't cover) falls back to the empty no-op module rather than
+ * failing the build outright — the SAME degraded-but-shippable behavior
+ * as before this fix for whatever slice of cases it doesn't cover,
+ * rather than a regression for OTHER apps that build cleanly today.
+ */
+/** The single virtual module id an UNRESOLVED `@bf-child:` marker falls
+ * back to — one shared id (not one per child name) because the module's
+ * content is always the same (empty) and Rollup dedupes same-id imports
+ * for free. */
+export declare const BF_CHILD_NOOP_ID = "\0barefoot-bf-child-noop";
+/** The child component name embedded in a `@bf-child:` marker, or `null`
+ * if `source` doesn't look like a compiler-emitted one. */
+export declare function bfChildMarkerName(source: string): string | null;
+//# sourceMappingURL=child-marker.d.ts.map

package/dist/child-marker.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"child-marker.d.ts","sourceRoot":"","sources":["../src/child-marker.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoDG;AAIH;;;eAGe;AACf,eAAO,MAAM,gBAAgB,6BAA6B,CAAA;AAE1D;2DAC2D;AAC3D,wBAAgB,iBAAiB,CAAC,MAAM,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAE/D"}

package/dist/compile-cache.d.ts

@@ -0,0 +1,19 @@
+import type { CompileResult } from '@barefootjs/jsx';
+export declare class CompileCache {
+    private rows;
+    /**
+     * Return the cached `CompileResult` for `absPath` if its content hash
+     * matches what's cached; otherwise call `compile()`, cache the result,
+     * and return it. `compile()` runs at most once per distinct
+     * `(absPath, content)` pair.
+     */
+    getOrCompile(absPath: string, content: string, compile: () => CompileResult): CompileResult;
+    /** Look up a previously cached result without recompiling. */
+    peek(absPath: string): CompileResult | undefined;
+    /** Drop a single file's cached entry — used when a file is deleted
+     * (dev watcher `'unlink'`) so a later file recreated at the same path
+     * never reuses a stale result keyed only by path, not content. */
+    delete(absPath: string): void;
+    clear(): void;
+}
+//# sourceMappingURL=compile-cache.d.ts.map

package/dist/compile-cache.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"compile-cache.d.ts","sourceRoot":"","sources":["../src/compile-cache.ts"],"names":[],"mappings":"AAaA,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,iBAAiB,CAAA;AAWpD,qBAAa,YAAY;IACvB,OAAO,CAAC,IAAI,CAA8B;IAE1C;;;;;OAKG;IACH,YAAY,CACV,OAAO,EAAE,MAAM,EACf,OAAO,EAAE,MAAM,EACf,OAAO,EAAE,MAAM,aAAa,GAC3B,aAAa,CAQf;IAED,8DAA8D;IAC9D,IAAI,CAAC,OAAO,EAAE,MAAM,GAAG,aAAa,GAAG,SAAS,CAE/C;IAED;;sEAEkE;IAClE,MAAM,CAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAE5B;IAED,KAAK,IAAI,IAAI,CAEZ;CACF"}

package/dist/component-manifest.d.ts

@@ -0,0 +1,69 @@
+/**
+ * Reassembles ONE source file's row for the combined `manifest.json` this
+ * plugin writes to `templatesDir` alongside the per-component
+ * `<Name>.ssr-defaults.json` files `emit.ts`'s `planEmits` already produces.
+ *
+ * WHY THIS EXISTS (not just the per-component files): every PHP/Python/Ruby
+ * backend driving a `templatesPerComponent` adapter (Blade/Jinja2/ERB) reads
+ * `ssrDefaults` — an optional-prop-derived signal's SSR seed value — from
+ * disk at REQUEST time (there is no compile step to bake it into source the
+ * way Go's generated `NewXxxProps` constructor or Hono's self-contained
+ * `.tsx` file can). Combining every source file's row into one manifest
+ * means each backend reads a single file instead of glob-and-reassembling
+ * the identical `{ [component]: { ssrDefaults } }` shape itself — avoiding
+ * seven copies of the same reconstruction logic across three languages,
+ * each of which could drift or break independently. One place in core
+ * beats three `/vite` packages reimplementing it, and
+ * `@barefootjs/go-template/vite` / `@barefootjs/hono/vite` get the same
+ * manifest for free even though neither adapter's own backend currently
+ * reads it (Go bakes `ssrDefaults` into generated source; Hono's `.tsx`
+ * inlines them as JS defaults) — see this module's own callers for the
+ * confirmation that neither reads a manifest today.
+ *
+ * Implemented standalone rather than by importing from `@barefootjs/cli`,
+ * for the same reason as `paths.ts`'s header comment: that package's only
+ * published entry point is the full `bf` binary.
+ *
+ * Two fields are deliberately NOT part of `ManifestEntry`:
+ *
+ * - `stubDeps` is not emitted: Rollup's own module graph resolution
+ *   handles dependency wiring, so there is no separate stub-dependency
+ *   bookkeeping to produce, and no consumer reads such a field.
+ * - `clientJs` is not emitted: there is no single static path to put
+ *   there. The real client JS URL is content-hashed and mode-dependent
+ *   (dev-origin vs. build-manifest-resolved) — exactly what
+ *   `scriptAssets` already resolves and bakes directly into the compiled
+ *   template's own script-registration call. No adapter backend or native
+ *   runtime reads `manifest[name].clientJs`; however, `@barefootjs/hono`'s
+ *   `BfPreload` component can read `clientJs` from a caller-supplied
+ *   manifest object (legacy site builds emit one). Plugin-manifest
+ *   consumers wanting preloads use the `preloadAssets` path instead
+ *   (`registerComponentPreloads` → `<link rel="modulepreload">`).
+ */
+import type { CompileResult, TemplateAdapter } from '@barefootjs/jsx';
+/** One exported component's row inside a multi-export source file's
+ * `components` map (`templatesPerComponent` adapters only). */
+export interface ManifestComponentEntry {
+    markedTemplate: string;
+    ssrDefaults?: Record<string, unknown>;
+}
+/** One SOURCE FILE's row in the combined manifest (see this module's
+ * header for the fields intentionally not included). */
+export interface ManifestEntry {
+    markedTemplate: string;
+    ssrDefaults?: Record<string, unknown>;
+    /** Per-exported-component rows for `templatesPerComponent` adapters
+     * (piconic-ai/barefootjs#2132) — present even for a single-component
+     * file. */
+    components?: Record<string, ManifestComponentEntry>;
+}
+/**
+ * Builds one source file's `{ manifestKey, entry }` pair from its
+ * already-compiled `CompileResult`. Returns `null` when the compile
+ * produced no `markedTemplate` at all (nothing to register).
+ */
+export declare function buildManifestEntry(result: CompileResult, absPath: string, componentDirs: readonly string[], adapter: TemplateAdapter): {
+    manifestKey: string;
+    entry: ManifestEntry;
+} | null;
+//# sourceMappingURL=component-manifest.d.ts.map

package/dist/component-manifest.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"component-manifest.d.ts","sourceRoot":"","sources":["../src/component-manifest.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAyCG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,iBAAiB,CAAA;AAGrE;+DAC+D;AAC/D,MAAM,WAAW,sBAAsB;IACrC,cAAc,EAAE,MAAM,CAAA;IACtB,WAAW,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAA;CACtC;AAED;wDACwD;AACxD,MAAM,WAAW,aAAa;IAC5B,cAAc,EAAE,MAAM,CAAA;IACtB,WAAW,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAA;IACrC;;eAEW;IACX,UAAU,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,sBAAsB,CAAC,CAAA;CACpD;AAED;;;;GAIG;AACH,wBAAgB,kBAAkB,CAChC,MAAM,EAAE,aAAa,EACrB,OAAO,EAAE,MAAM,EACf,aAAa,EAAE,SAAS,MAAM,EAAE,EAChC,OAAO,EAAE,eAAe,GACvB;IAAE,WAAW,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,aAAa,CAAA;CAAE,GAAG,IAAI,CAiEtD"}

package/dist/corpus-program.d.ts

@@ -0,0 +1,41 @@
+import type ts from 'typescript';
+export declare class CorpusProgramManager {
+    private program;
+    private roots;
+    /**
+     * (Re)build the corpus Program from a full discovery pass's snapshot.
+     * Filters `files` down to the ones needing type-based detection; no-ops
+     * entirely (keeping the existing Program) when the root set and every
+     * root's on-Program text are unchanged — the common case for the dev
+     * watcher's full re-runs, where `CompileCache` already makes unchanged
+     * files free and this keeps the Program free too.
+     *
+     * Callers pass the content DISCOVERY read, and `createProgramForCorpus`'s
+     * host re-reads from disk — the two can only diverge if the file changed
+     * in the microseconds between, and `programFor`'s per-file text check
+     * catches exactly that before any compile trusts the Program.
+     */
+    seed(files: readonly {
+        absPath: string;
+        content: string;
+    }[]): void;
+    /**
+     * The Program to pass as `CompileOptions.program` when compiling
+     * `absPath` with `content` — or `undefined` when the file doesn't need
+     * type-based detection at all (the analyzer then never builds a checker,
+     * and passing nothing costs nothing).
+     *
+     * Handles the two ways the seeded Program can be behind reality:
+     * - `absPath` isn't a root yet (a needing file created after the last
+     *   seed, reached by the graph pass before the next eager pass) or its
+     *   disk content changed: add the root and rebuild incrementally.
+     * - `content` diverges from what's on disk even after a rebuild (an
+     *   in-flight edit): fall back to a virtual single-file Program built
+     *   from `content` itself — the pre-manager per-file behavior, correct
+     *   and BF050-suppressing, just slow, and only for that one file until
+     *   disk catches up.
+     */
+    programFor(absPath: string, content: string): ts.Program | undefined;
+    private rebuild;
+}
+//# sourceMappingURL=corpus-program.d.ts.map

package/dist/corpus-program.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"corpus-program.d.ts","sourceRoot":"","sources":["../src/corpus-program.ts"],"names":[],"mappings":"AAiCA,OAAO,KAAK,EAAE,MAAM,YAAY,CAAA;AAOhC,qBAAa,oBAAoB;IAC/B,OAAO,CAAC,OAAO,CAAwB;IACvC,OAAO,CAAC,KAAK,CAAoB;IAEjC;;;;;;;;;;;;OAYG;IACH,IAAI,CAAC,KAAK,EAAE,SAAS;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,CAAA;KAAE,EAAE,GAAG,IAAI,CAqBjE;IAED;;;;;;;;;;;;;;;OAeG;IACH,UAAU,CAAC,OAAO,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,GAAG,EAAE,CAAC,OAAO,GAAG,SAAS,CAcnE;IAED,OAAO,CAAC,OAAO;CAYhB"}

package/dist/debounced-serial-runner.d.ts

@@ -0,0 +1,27 @@
+/**
+ * Debounce + serialize an async task behind a single `trigger()` entry
+ * point. Built for `configureServer`'s watcher handlers: a burst of
+ * `'change'`/`'add'`/`'unlink'` events (save-twice-quickly, a multi-file
+ * save, a `git checkout` touching many files) must not start several
+ * overlapping eager passes writing the same template files.
+ *
+ * Two, deliberately separate, guarantees:
+ *  - **debounce**: `trigger()` calls within `debounceMs` of each other
+ *    collapse into a single scheduled run.
+ *  - **serialize + coalesce**: if `task()` is still running when the
+ *    debounce timer fires, this does NOT start a second, overlapping
+ *    call — it marks exactly one follow-up run, which starts the instant
+ *    the in-flight one finishes. A change arriving mid-pass is delayed,
+ *    never dropped, and at most one run is ever in flight.
+ *
+ * Deliberately minimal: no queue of distinct payloads, no rehashing —
+ * `task()` itself (the caller's full eager pass) is the unit of work, and
+ * it re-discovers everything from disk on every call, so "run it again"
+ * is always correct regardless of how many trigger()s piled up.
+ */
+export interface DebouncedSerialRunner {
+    /** Schedule a run, debounced. Safe to call from multiple event sources. */
+    trigger(): void;
+}
+export declare function createDebouncedSerialRunner(task: () => Promise<void>, debounceMs: number, onError: (err: unknown) => void): DebouncedSerialRunner;
+//# sourceMappingURL=debounced-serial-runner.d.ts.map

package/dist/debounced-serial-runner.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"debounced-serial-runner.d.ts","sourceRoot":"","sources":["../src/debounced-serial-runner.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,WAAW,qBAAqB;IACpC,2EAA2E;IAC3E,OAAO,IAAI,IAAI,CAAA;CAChB;AAED,wBAAgB,2BAA2B,CACzC,IAAI,EAAE,MAAM,OAAO,CAAC,IAAI,CAAC,EACzB,UAAU,EAAE,MAAM,EAClB,OAAO,EAAE,CAAC,GAAG,EAAE,OAAO,KAAK,IAAI,GAC9B,qBAAqB,CAoCvB"}

package/dist/dev-server.d.ts

@@ -0,0 +1,99 @@
+import type { ResolvedConfig, ViteDevServer } from 'vite';
+/**
+ * Localhost-only CORS default this plugin fills in — ONLY when the user
+ * hasn't configured `server.cors` themselves (see the `config` hook in
+ * `plugin.ts`). Vite 6+ defaults `cors` to same-origin-only, which breaks
+ * the cross-origin split this plugin sets up (the page is rendered by the
+ * backend on its own origin; modules are served by Vite on another)
+ * unless something opts localhost origins in. Deliberately not a wildcard
+ * `true` — see the PR brief for the reasoning.
+ */
+export declare const DEFAULT_DEV_CORS_ORIGIN: RegExp;
+/**
+ * Debounce window (ms) for the dev watcher's `'change'` / `'add'` /
+ * `'unlink'` handlers — long enough to coalesce a save-twice-quickly or a
+ * multi-file save/`git checkout` into a single eager pass, short enough
+ * that a reload still feels instant.
+ */
+export declare const DEV_WATCH_DEBOUNCE_MS = 100;
+/**
+ * The request path (relative to `config.base`, no leading slash) a browser
+ * must use to reach `absPath` through Vite's dev server: a root-relative
+ * path when `absPath` is under `config.root`, or Vite's `/@fs/`
+ * absolute-path passthrough when it isn't.
+ */
+export declare function devRequestPath(config: Pick<ResolvedConfig, 'root'>, absPath: string): string;
+/** Full absolute URL (origin + `base` + request path) for `absPath` under
+ * the dev server. */
+export declare function devModuleUrl(config: Pick<ResolvedConfig, 'root' | 'base'>, origin: string, absPath: string): string;
+/**
+ * The ordered `scriptAssets` a `'use client'` component needs in dev: the
+ * `@vite/client` HMR/full-reload socket first (so the page always gets a
+ * live-reload connection), then the component's own module — Vite serves
+ * it plain-JS via this plugin's `transform` hook exactly like it would any
+ * other dev module, no different from a production entry. Per the design,
+ * server-only components (no `'use client'`) get `[]` — computed by the
+ * caller without consulting this function at all, see `plugin.ts`.
+ */
+export declare function devScriptAssets(config: Pick<ResolvedConfig, 'root' | 'base'>, origin: string, absPath: string): string[];
+/**
+ * The dev origin to bake into `scriptAssets`: the user's own
+ * `server.origin` if they set one, otherwise `http://localhost:<port>`
+ * using the port Vite actually bound — NOT the configured port, which can
+ * be wrong (Vite auto-increments past an in-use port unless `strictPort`
+ * is set). Also writes the computed default back onto
+ * `server.config.server.origin` so Vite's OWN asset-URL rewriting
+ * (`import.meta.url`, CSS `url()`, etc.) agrees with the URLs this plugin
+ * bakes into templates — both need to match for the cross-origin split
+ * (page from the backend, assets from Vite) to work end to end.
+ *
+ * Call only after the server is actually listening (`httpServer`'s
+ * `'listening'` event) — the resolved port isn't known before then.
+ */
+export declare function resolveDevOrigin(server: ViteDevServer): string;
+/**
+ * Filename of the marker BarefootJS writes at the root of `templates`
+ * while the dev server is running, so a stray `git add` or a production
+ * deploy of dev-only output (localhost URLs baked into every template) is
+ * obvious before it ships. `writeBundle` (the `vite build` path) removes
+ * it — see `plugin.ts`.
+ *
+ * A per-template, per-adapter comment (Go `{{/* … *\/}}`, ERB `<%# … %>`,
+ * etc.) would pinpoint the problem more precisely, but needs new surface
+ * on every `TemplateAdapter` implementation across 9+ adapter packages —
+ * out of scope for a dev-server PR that touches none of them. The brief
+ * explicitly allows this single-file fallback in that case.
+ */
+export declare const DEV_ARTIFACT_MARKER_FILENAME = ".barefootjs-dev-build";
+export declare const DEV_ARTIFACT_MARKER_CONTENT = "This directory currently holds DEV BUILD OUTPUT from @barefootjs/vite's\ndev server, not a production build.\n\nEvery template in this directory has dev-only URLs baked into it\n(http://localhost:<port>/...) pointing at the Vite dev server. They will\nbreak if committed, deployed, or served without that dev server running.\n\nRun `vite build` to regenerate this directory with real, hashed,\nproduction asset URLs \u2014 the build overwrites every template here and\nremoves this file.\n";
+/**
+ * Cross-language dev-reload sentinel: `<outDir>/.dev/build-id`, ONE
+ * DIRECTORY ABOVE `templates`. The path is fixed, not derived from
+ * `templatesDir`, because several server runtimes below poll this exact
+ * location.
+ *
+ * Several adapter runtimes poll this exact path for a value change and
+ * push an SSE `event: reload` on it — a mechanism that does NOT require
+ * the polling process to restart, only the file's mtime/content to
+ * change: `bfdev.NewReloadHandler` (Go — echo/gin/chi/nethttp),
+ * `Mojolicious::Plugin::BarefootJS::DevReload` /
+ * `BarefootJS::DevReload` (Perl — mojolicious/xslate), and
+ * `barefoot_js/dev_reload.rb` (Ruby — sinatra/rails, ERB). `vite dev` is
+ * the only piece of the dev loop those adapters' apps run alongside — if
+ * this plugin didn't write the sentinel, nothing would, and their reload
+ * handlers would never fire.
+ *
+ * Hono's dev-reload story does not consume this at all: both its
+ * Cloudflare Workers target (`dev-worker.ts`'s boot id) and its Node
+ * target (`barefootDevReload`'s SSE endpoint, wired up in the scaffold's
+ * `factory.ts`) detect a restart directly over their own SSE connection,
+ * no file involved. Writing this sentinel unconditionally whenever
+ * `templates` is configured is harmless there — nothing reads it — which
+ * is what keeps this a zero-config, adapter-agnostic signal rather than a
+ * 4th plugin option naming which adapters want it.
+ */
+export declare const DEV_SENTINEL_SUBDIR = ".dev";
+export declare const DEV_SENTINEL_FILENAME = "build-id";
+/** Absolute path of the dev-reload sentinel for a given `templates` dir. */
+export declare function devSentinelPath(templatesDir: string): string;
+//# sourceMappingURL=dev-server.d.ts.map

package/dist/dev-server.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"dev-server.d.ts","sourceRoot":"","sources":["../src/dev-server.ts"],"names":[],"mappings":"AAgBA,OAAO,KAAK,EAAE,cAAc,EAAE,aAAa,EAAE,MAAM,MAAM,CAAA;AAczD;;;;;;;;GAQG;AACH,eAAO,MAAM,uBAAuB,QAAiD,CAAA;AAErF;;;;;GAKG;AACH,eAAO,MAAM,qBAAqB,MAAM,CAAA;AAQxC;;;;;GAKG;AACH,wBAAgB,cAAc,CAAC,MAAM,EAAE,IAAI,CAAC,cAAc,EAAE,MAAM,CAAC,EAAE,OAAO,EAAE,MAAM,GAAG,MAAM,CAM5F;AAED;qBACqB;AACrB,wBAAgB,YAAY,CAC1B,MAAM,EAAE,IAAI,CAAC,cAAc,EAAE,MAAM,GAAG,MAAM,CAAC,EAC7C,MAAM,EAAE,MAAM,EACd,OAAO,EAAE,MAAM,GACd,MAAM,CAER;AAED;;;;;;;;GAQG;AACH,wBAAgB,eAAe,CAC7B,MAAM,EAAE,IAAI,CAAC,cAAc,EAAE,MAAM,GAAG,MAAM,CAAC,EAC7C,MAAM,EAAE,MAAM,EACd,OAAO,EAAE,MAAM,GACd,MAAM,EAAE,CAKV;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,gBAAgB,CAAC,MAAM,EAAE,aAAa,GAAG,MAAM,CAS9D;AAED;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,4BAA4B,0BAA0B,CAAA;AAEnE,eAAO,MAAM,2BAA2B,8eAUvC,CAAA;AAED;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,eAAO,MAAM,mBAAmB,SAAS,CAAA;AACzC,eAAO,MAAM,qBAAqB,aAAa,CAAA;AAE/C,4EAA4E;AAC5E,wBAAgB,eAAe,CAAC,YAAY,EAAE,MAAM,GAAG,MAAM,CAE5D"}

package/dist/discover.d.ts

@@ -0,0 +1,117 @@
+/** Does `content` start with a `'use client'` / `"use client"` directive
+ * (after skipping leading block/line comments)? */
+export declare function hasUseClientDirective(content: string): boolean;
+/**
+ * Is `name` (a bare filename, not a path) a component source file this
+ * plugin should discover/compile? `.tsx`, excluding `.test.tsx`,
+ * `.spec.tsx`, and `.preview.tsx`. Exported separately from
+ * `discoverComponentFiles` so the dev-server file watcher (`plugin.ts`'s
+ * `configureServer`) can apply the exact same filter to a single changed
+ * path without re-walking a directory.
+ */
+export declare function isComponentSourceFile(name: string): boolean;
+/**
+ * Recursively discover `.tsx` component files in a directory.
+ * Skips `.test.tsx`, `.spec.tsx`, and `.preview.tsx` files.
+ */
+export declare function discoverComponentFiles(dir: string, options?: {
+    skipDirs?: string[];
+}): Promise<string[]>;
+export interface DiscoveredComponent {
+    /** Absolute path to the `.tsx` source file. */
+    absPath: string;
+    /**
+     * The file's full source text, as read by the discovery pass. Retained
+     * (discovery had to read it anyway for the directive/exports checks) so
+     * downstream consumers — the corpus-program seeding and the eager pass's
+     * compile loop — work from the SAME snapshot discovery classified,
+     * instead of re-reading and racing an edit that landed in between.
+     */
+    content: string;
+    /** Whether the file's content starts with a `'use client'` directive. */
+    isClient: boolean;
+    /**
+     * Every component this file exports, from `@barefootjs/jsx`'s TS-AST
+     * walk (`listExportedComponents`) — never a regex, and never the
+     * basename standing in for the name. A file exporting more than one
+     * component (`icon/index.tsx` → `CopyIcon` + `CheckIcon`) is why this
+     * exists; see `buildChildNameIndex`.
+     */
+    exportedComponents: string[];
+    /**
+     * `CompileOptions.cssLayerPrefix` this file should compile with, carried
+     * over unchanged from whichever `components` entry's `dir` this file was
+     * discovered under (see `ResolvedComponentDirEntry.cssLayerPrefix`).
+     * `undefined` when that entry set none (or was a plain string entry).
+     */
+    cssLayerPrefix?: string;
+}
+/**
+ * A `components` directory to scan, already resolved to an absolute `dir`,
+ * plus the per-directory compile behavior `barefoot()`'s `ComponentDirEntry`
+ * (`types.ts`) carries. `discoverComponents` also accepts a plain absolute
+ * path string as shorthand for `{ dir: string }` — the same "string is
+ * exactly equivalent to `{ dir }`" equivalence `ComponentDirEntry` itself
+ * documents — so existing callers that only ever had bare directories
+ * (`integrations/h3`/`elysia`'s `vite.config.ts`, reusing this exported
+ * function to resolve every discovered client component's URL) keep
+ * compiling and behaving unchanged.
+ */
+export interface ResolvedComponentDirEntry {
+    /** Absolute path to the source directory to scan. */
+    dir: string;
+    /** Stamped onto every `DiscoveredComponent` found under `dir` — see
+     * `DiscoveredComponent.cssLayerPrefix`. */
+    cssLayerPrefix?: string;
+    /** Directory NAMES to skip anywhere under `dir` — passed straight
+     * through to `discoverComponentFiles`. */
+    skipDirs?: string[];
+}
+/**
+ * Scan every configured `components` directory for `.tsx` files and
+ * classify each as client (`'use client'`) or server-only. Each entry may
+ * be a plain absolute path (shorthand for `{ dir }`, no `cssLayerPrefix`/
+ * `skipDirs`) or a `ResolvedComponentDirEntry`.
+ *
+ * A file reachable under more than one entry is discovered once, stamped
+ * with the FIRST matching entry's `cssLayerPrefix` — entries are walked in
+ * array order and `seen` short-circuits every later match, the same
+ * first-writer-wins precedence `buildChildNameIndex` already documents for
+ * `@bf-child:` name collisions.
+ */
+export declare function discoverComponents(entries: readonly (string | ResolvedComponentDirEntry)[], readFile: (absPath: string) => Promise<string>): Promise<DiscoveredComponent[]>;
+/**
+ * Component-name → absolute-path index used to resolve `@bf-child:<Name>`
+ * markers (see `child-marker.ts`) to a real file: a bare-marker child
+ * reference embeds only the referenced component's NAME (the compiler has
+ * no filesystem access at that phase — see `child-components.ts`), so
+ * `resolveId` needs a name→file lookup built from a full discovery pass.
+ *
+ * Keyed by each exported component NAME, which is what the marker
+ * carries. Server-only files are excluded: a `@bf-child:` marker only
+ * ever names another component this one instantiates at runtime
+ * (`initChild`/`createComponent`), which requires an `init` function only
+ * a `'use client'` file has.
+ *
+ * This used to key on the file's basename, which worked only because the
+ * one-component-per-file convention makes the two coincide
+ * (`TodoItem.tsx` exports `TodoItem`). A file exporting several
+ * components broke it silently: `icon/index.tsx` was keyed `index`, so
+ * `@bf-child:CopyIcon` found nothing and fell through to the no-op module
+ * (`plugin.ts`'s `resolveId`) — a child that never hydrates, with no
+ * diagnostic.
+ *
+ * The blast radius was wider than multi-export files. Because the key was
+ * the bare basename, EVERY colocated `index.tsx` collided on the single
+ * key `"index"` — including single-export ones like `ui/button/index.tsx`
+ * exporting `Button`. No colocated component was reachable as a
+ * `@bf-child:` target at all, whatever its export count. Measured with
+ * `listExportedComponents` over `ui/components` + `site/ui/components`:
+ * 112 files export more than one component, 105 of them `'use client'`.
+ *
+ * First writer wins on a duplicate name, and discovery order is the
+ * `components` option's order — so an earlier directory shadows a later
+ * one, the same precedence the option list already implies.
+ */
+export declare function buildChildNameIndex(discovered: readonly Pick<DiscoveredComponent, 'absPath' | 'isClient' | 'exportedComponents'>[]): Map<string, string>;
+//# sourceMappingURL=discover.d.ts.map

package/dist/discover.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"discover.d.ts","sourceRoot":"","sources":["../src/discover.ts"],"names":[],"mappings":"AAeA;mDACmD;AACnD,wBAAgB,qBAAqB,CAAC,OAAO,EAAE,MAAM,GAAG,OAAO,CAe9D;AAED;;;;;;;GAOG;AACH,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAO3D;AAED;;;GAGG;AACH,wBAAsB,sBAAsB,CAC1C,GAAG,EAAE,MAAM,EACX,OAAO,CAAC,EAAE;IAAE,QAAQ,CAAC,EAAE,MAAM,EAAE,CAAA;CAAE,GAChC,OAAO,CAAC,MAAM,EAAE,CAAC,CAwBnB;AAED,MAAM,WAAW,mBAAmB;IAClC,+CAA+C;IAC/C,OAAO,EAAE,MAAM,CAAA;IACf;;;;;;OAMG;IACH,OAAO,EAAE,MAAM,CAAA;IACf,yEAAyE;IACzE,QAAQ,EAAE,OAAO,CAAA;IACjB;;;;;;OAMG;IACH,kBAAkB,EAAE,MAAM,EAAE,CAAA;IAC5B;;;;;OAKG;IACH,cAAc,CAAC,EAAE,MAAM,CAAA;CACxB;AAED;;;;;;;;;;GAUG;AACH,MAAM,WAAW,yBAAyB;IACxC,qDAAqD;IACrD,GAAG,EAAE,MAAM,CAAA;IACX;+CAC2C;IAC3C,cAAc,CAAC,EAAE,MAAM,CAAA;IACvB;8CAC0C;IAC1C,QAAQ,CAAC,EAAE,MAAM,EAAE,CAAA;CACpB;AAED;;;;;;;;;;;GAWG;AACH,wBAAsB,kBAAkB,CACtC,OAAO,EAAE,SAAS,CAAC,MAAM,GAAG,yBAAyB,CAAC,EAAE,EACxD,QAAQ,EAAE,CAAC,OAAO,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC,GAC7C,OAAO,CAAC,mBAAmB,EAAE,CAAC,CAuBhC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,wBAAgB,mBAAmB,CAIjC,UAAU,EAAE,SAAS,IAAI,CAAC,mBAAmB,EAAE,SAAS,GAAG,UAAU,GAAG,oBAAoB,CAAC,EAAE,GAC9F,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,CAerB"}

package/dist/emit.d.ts

@@ -0,0 +1,9 @@
+import type { CompileResult, TemplateAdapter } from '@barefootjs/jsx';
+export interface EmitTarget {
+    /** POSIX path, relative to the `templates` dir. */
+    relPath: string;
+    content: string;
+}
+export declare function planEmits(result: CompileResult, absPath: string, componentDirs: readonly string[], adapter: TemplateAdapter): EmitTarget[];
+export declare function writeEmits(templatesDir: string, targets: EmitTarget[]): Promise<void>;
+//# sourceMappingURL=emit.d.ts.map

package/dist/emit.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"emit.d.ts","sourceRoot":"","sources":["../src/emit.ts"],"names":[],"mappings":"AAoBA,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,iBAAiB,CAAA;AAGrE,MAAM,WAAW,UAAU;IACzB,mDAAmD;IACnD,OAAO,EAAE,MAAM,CAAA;IACf,OAAO,EAAE,MAAM,CAAA;CAChB;AAED,wBAAgB,SAAS,CACvB,MAAM,EAAE,aAAa,EACrB,OAAO,EAAE,MAAM,EACf,aAAa,EAAE,SAAS,MAAM,EAAE,EAChC,OAAO,EAAE,eAAe,GACvB,UAAU,EAAE,CAuBd;AAED,wBAAsB,UAAU,CAAC,YAAY,EAAE,MAAM,EAAE,OAAO,EAAE,UAAU,EAAE,GAAG,OAAO,CAAC,IAAI,CAAC,CAM3F"}

package/dist/index.d.ts

@@ -0,0 +1,8 @@
+export { barefoot, PLUGIN_NAME } from './plugin.ts';
+export { barefoot as default } from './plugin.ts';
+export type { AfterEmitContext, BarefootPluginApi, BarefootViteOptions, ComponentDirEntry } from './types.ts';
+export { loadManifest, resolveScriptAssets, joinBaseAndFile } from './manifest.ts';
+export { devModuleUrl, devRequestPath, resolveDevOrigin } from './dev-server.ts';
+export { toPosixRelative } from './paths.ts';
+export { discoverComponents, type DiscoveredComponent, type ResolvedComponentDirEntry } from './discover.ts';
+//# sourceMappingURL=index.d.ts.map

package/dist/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,QAAQ,EAAE,WAAW,EAAE,MAAM,aAAa,CAAA;AACnD,OAAO,EAAE,QAAQ,IAAI,OAAO,EAAE,MAAM,aAAa,CAAA;AACjD,YAAY,EAAE,gBAAgB,EAAE,iBAAiB,EAAE,mBAAmB,EAAE,iBAAiB,EAAE,MAAM,YAAY,CAAA;AAO7G,OAAO,EAAE,YAAY,EAAE,mBAAmB,EAAE,eAAe,EAAE,MAAM,eAAe,CAAA;AAClF,OAAO,EAAE,YAAY,EAAE,cAAc,EAAE,gBAAgB,EAAE,MAAM,iBAAiB,CAAA;AAChF,OAAO,EAAE,eAAe,EAAE,MAAM,YAAY,CAAA;AAa5C,OAAO,EAAE,kBAAkB,EAAE,KAAK,mBAAmB,EAAE,KAAK,yBAAyB,EAAE,MAAM,eAAe,CAAA"}