@barefootjs/go-template 0.33.4 → 0.34.0

package/src/adapter/lib/compile-state.ts

@@ -38,6 +38,24 @@ export class CompileState {
    *  that's resolvable and non-colliding. */
   referencedDerivedConsts: Set<string> = new Set()
 
+  /**
+   * Root-scope field names (signal getters, memo names, props, derived
+   * consts) the SSR template actually READ while rendering — recorded by
+   * `rootFieldRef`, the single door every such read passes through
+   * (`identifier`/`call`/`member`'s zero-arg-getter and bare-name lowering,
+   * plus the typed-expression emitter). `generateTypes` (#2700) consults
+   * this AFTER `generate()` has rendered the template to decide whether a
+   * signal whose object-literal initializer the constructor-time baker
+   * can't reproduce (`convertInitialValue` returning null) needs a loud
+   * BF101 refusal: a deferred bake that is NEVER read by the template (e.g.
+   * only feeds a spread-attrs bag, which routes through its own
+   * `.Spread_<slot>` field, never this set) silently keeping its Go zero
+   * value is harmless, so refusing it would be a false positive — see
+   * `refuseUnbakeableDerivedObjectLiteral`'s docstring for why the check is
+   * call-site-aware instead of firing at the bake site itself.
+   */
+  templateReadRootFields: Set<string> = new Set()
+
   templateVarCounter: number = 0
 
   /**

package/src/adapter/value/parsed-literal-to-go.ts

@@ -28,13 +28,17 @@ import { goFieldNameForKey } from '../lib/go-naming.ts'
 import { typeInfoToGo } from '../type/type-codegen.ts'
 
 /**
- * Look up a struct property's declared `TypeInfo` by source key, from the
- * user's own `TypeDefinition` (not a synthesized struct — those only arise
- * from an UNTYPED literal, which never carries nested object/array elements
- * because `synthesizeStructFromSignal` requires every property value to be a
- * scalar literal). Returns undefined when the struct name isn't a user type
- * or the key isn't declared — callers treat that as "nested type unknown"
- * and fall back to the generic/inline lowering.
+ * Look up a struct property's declared `TypeInfo` by source key. Resolves
+ * against ANY registered `TypeDefinition` — a user-written type, a #2674
+ * anonymous-object synthesis, or (#2800) an untyped-literal signal struct
+ * synthesized by `synthesizeStructFromSignal`, which pushes one
+ * `TypeDefinition` per struct (top-level and nested) via the same
+ * `registerSynthStruct` door #2674 uses, specifically so a nested
+ * array-of-objects field's declared element type is findable here exactly
+ * like a user-declared nested property's is. Returns undefined when the
+ * struct name isn't registered or the key isn't declared — callers treat
+ * that as "nested type unknown" and fall back to the generic/inline
+ * lowering.
  */
 function structPropertyType(ctx: GoEmitContext, structGoType: string, key: string): TypeInfo | undefined {
   const td = ctx.state.currentTypeDefinitions.find((t: TypeDefinition) => t.name === structGoType)

package/src/adapter/value/value-lowering.ts

@@ -94,6 +94,23 @@ export function convertInitialValue(
     if (param) {
       return propRef(param)
     }
+    // Module-const seed (#2794): a signal seeded from a bare identifier
+    // that refers to a module-level const (`const PAYLOAD = 'x';
+    // createSignal(PAYLOAD)`) types `unknown` — the analyzer's type
+    // inference is text-shaped and never chases an identifier to its
+    // declaration — so none of the typed branches below ever see it and
+    // this used to fall through to the final `nil`. Checked AFTER the
+    // prop lookup so a destructured prop that happens to share the
+    // const's name still wins (shadowing). Both resolvers return null
+    // for anything that isn't a statically-inlinable module const
+    // (a call-initialized const, a loop var, a component-scope const),
+    // leaving that case on the pre-existing `nil` path unchanged.
+    const inlinedStr = ctx.resolveModuleStringConst(value)
+    if (inlinedStr !== null) return inlinedStr
+    const inlinedNum = ctx.resolveModuleNumericConst(value)
+    if (inlinedNum !== null) return inlinedNum
+    const inlinedBool = ctx.resolveModuleBooleanConst(value)
+    if (inlinedBool !== null) return inlinedBool
   }
 
   const propName = ctx.extractPropNameFromInitialValue(value, preParsed)

package/src/conformance-pins.ts

@@ -76,4 +76,23 @@ export const conformancePins: ConformancePins = {
     issue: 'https://github.com/piconic-ai/barefootjs/issues/2805',
     unescapable: { issue: 'https://github.com/piconic-ai/barefootjs/issues/2805' },
   }],
+  // #2700: a `derived` signal/memo (non-empty free set) seeded from an
+  // object literal the constructor-time baker can't reproduce (identifier/
+  // member/call operands defer, `parsed-literal-to-go.ts`) now refuses
+  // loudly instead of silently keeping the Go zero value — this fixture's
+  // `merged().id` / `merged().done` reads are exactly that shape. A working
+  // `/* @client */` escape twin exists (`signal-object-spread-init-client`),
+  // verified to render correctly, so no `unescapable`.
+  'signal-object-spread-init': [{
+    code: 'BF101',
+    severity: 'error',
+    issue: 'https://github.com/piconic-ai/barefootjs/issues/2700',
+  }],
+  // #2771: a reactive primitive invoked through a namespace import
+  // (`import * as bf from '@barefootjs/client'`, `bf.createSignal(...)`)
+  // that the analyzer's checker-less fast path cannot recognize refuses
+  // loudly (BF013) instead of silently dropping the declaration — fired
+  // in the shared analyzer pass ahead of any adapter's `adapter.generate()`,
+  // so all nine adapters (including Hono) pin this identically.
+  'namespace-import-primitive': [{ code: 'BF013', severity: 'error', issue: 'https://github.com/piconic-ai/barefootjs/issues/2771' }],
 }

package/src/render-divergences.ts

@@ -23,6 +23,16 @@
  * Go, so it moved off this table. Dynamic delivery for named jsx-children
  * props (the actual capability gap) is tracked separately at
  * https://github.com/piconic-ai/barefootjs/issues/2703.)
+ *
+ * (#2700's `signal-object-spread-init` divergence graduated the same way —
+ * by reclassification, not a lowering fix: a `derived` signal/memo's
+ * object-literal initializer referencing a live prop/signal has no
+ * live-template-expression lowering on Go, only a static constructor-time
+ * baker — now a loud `BF101` refusal (`conformance-pins.ts`) with a
+ * verified `/* @client *\/` escape twin (`signal-object-spread-init-client`),
+ * instead of a silent wrong render. Teaching the baker to emit
+ * prop-referencing Go expressions — the actual capability gap — stays
+ * tracked at https://github.com/piconic-ai/barefootjs/issues/2700.)
  */
 
 import type { RenderDivergences } from '@barefootjs/jsx'
@@ -30,10 +40,6 @@ import type { RenderDivergences } from '@barefootjs/jsx'
 export const renderDivergences: RenderDivergences = {
   'children-passthrough-renamed':
     'A `children` prop destructured under a different name (`const { children: kids } = props`) does not reach the SSR template on Go, tracked as https://github.com/piconic-ai/barefootjs/issues/2788. The same fixture also fails on Mojolicious, where the mechanism IS isolated: the `.html.ep` interpolates the LOCAL alias (`$kids`) while the stash defines only the caller-facing `children`, so the Perl render dies inside `Mojo::Template::process`. Go\'s own failure mode has NOT been read — `go` is not reachable from the local test process (the conformance case prints "go command not found" and skips), so this entry is declared from the CI failure on #2787 alone, not from a local reproduction. Whoever graduates this should read Go\'s actual output first rather than assume it shares Mojo\'s mechanism. Same alias family as `aliased-destructured-prop` (`{ n: count }`), whose Go half graduated in #2525 — worth checking whether the reserved `children` slot bypasses that fix or never had it. `children-passthrough-renamed` asserts the CORRECT (Hono-generated) output, so deleting this entry is the graduation.',
-  'signal-object-spread-init':
-    'PRE-EXISTING, unrelated to the #2696 Step 2 spread work this fixture pins: a `derived`-classified signal/memo whose value is an OBJECT literal has no live-template-expression lowering on Go — unlike the other six template-stash backends (e.g. minijinja emits `{% set merged = dict(base, done=true) %}`), Go always bakes an object-typed signal/memo field into Go SOURCE at `NewXxxProps` constructor time (`convertInitialValue`/`parsedLiteralToGo`), and that baker is STATIC-only (identifier/call/member operands defer, `parsed-literal-to-go.ts`\'s own docstring) — it cannot reference a live prop at all. Reproduced identically with the spread REMOVED (`createSignal({ id: base.id, done: true })`), confirming the gap predates and is independent of spread: the signal seeds `nil` and every field read (`.Merged.ID`/`.Merged.Done`) reads the Go zero value regardless of `initialTodos`. Graduate by teaching the baker to emit prop-referencing Go expressions (https://github.com/piconic-ai/barefootjs/issues/2700).',
-  'textarea-row-breakout':
-    'A signal seeded from a bare identifier referencing a MODULE-LEVEL const (`const PAYLOAD = \'...\'; createSignal(PAYLOAD)`) bakes to `nil` in the generated `New<Component>Props` constructor instead of the const\'s literal value: `convertInitialValue` (`value-lowering.ts`) only resolves a direct prop reference or a literal expression for a bare identifier, and the analyzer types this signal `{ kind: \'unknown\' }`, so every typed branch falls through to the final `nil` fallback. `resolveModuleStringConst` exists on the adapter for exactly this resolution (used by `template-interp.ts` for live template expressions) but isn\'t wired into this signal-baking path. Unrelated to what this fixture exists to cover (#2765\'s loop-row textarea-escaping fix, verified correct here) — every other adapter renders the fixture\'s controlled `<textarea>` correctly. Tracked at https://github.com/piconic-ai/barefootjs/issues/2794; graduate by wiring `resolveModuleStringConst` into `convertInitialValue`\'s bare-identifier case.',
-  'nested-loop-ref-const':
-    'A signal-backed object array whose elements have a NESTED array-of-objects field (`children: [{...}]`, producing this fixture\'s depth-2 `.map()`) bakes to `nil` in `New<Component>Props`, leaving the whole `{{range .Items}}` body empty on real Go — `synthesizeStructFromSignal` (`go-template-adapter.ts`) only synthesizes a struct when EVERY property value is a scalar literal (`scalarParsedGoType`), so a `children` array property aborts synthesis for the entire signal; `parsedLiteralToGo` then has no named struct to bake an object-literal element against and falls through to `nil`. Reproduced identically with #2750\'s fix reverted, confirming this predates and is independent of #2750 (which only touches client-JS reachability, never SSR baking) — every other adapter (confirmed: Hono) renders the nested loop correctly. Tracked at https://github.com/piconic-ai/barefootjs/issues/2800; graduate by teaching `synthesizeStructFromSignal` to recursively synthesize a nested struct for an array-valued property instead of bailing to `null`.',
+  'aliased-loop-source':
+    'A `.map()` loop whose source is a local const alias of a signal getter (`const items__alias = items`) fails template execution on real Go (`can\'t evaluate field Items__alias in type main.AliasedLoopSourceProps`) — the zero-arg-call-to-field lowering routes `items__alias()` to a `.Items__alias` struct field that was never seeded, since seeding only knows about `items`, the real signal name; the alias hop is never resolved. This is the SSR-side twin of #2778 (fixed for the CSR client-JS template in the same PR that added this fixture) — that fix only touches client-JS emission, not Go\'s field-routing/seeding. Tracked at https://github.com/piconic-ai/barefootjs/issues/2813; graduate by resolving the alias hop at field-routing time using the same `resolveAliasOrigin`/`resolveGetterAliases` mechanism #2778 introduced, rather than a third alias-hop walker.',
 }

package/src/test-render.ts

@@ -514,11 +514,10 @@ function collectImportedComponentNames(
     if (!imp.source.startsWith('.') && !childSpecifiers?.has(imp.source)) continue
     for (const spec of imp.specifiers ?? []) {
       if (spec.isNamespace) continue
-      // Imported binding name (the local alias is what JSX references, but the
-      // generated `{{define}}`/types are keyed by the exported component name —
-      // which equals the specifier name when un-aliased; aliased component
-      // imports aren't exercised by the UI fixtures).
-      names.push(spec.alias ?? spec.name)
+      // #2822: push `spec.name` (the child's own declared name), not
+      // `spec.alias ?? spec.name` — `childArtifacts` is keyed by each
+      // child's declared name, not the caller-local JSX/import binding.
+      names.push(spec.name)
     }
   }
   return names
@@ -595,16 +594,34 @@ function findBaseSignalGetter(expr: ParsedExpr | undefined, signalGetters: Reado
 /**
  * (#2630) Resolve a `isPropDerived` loop's `arrayParsed` to the JS-level
  * prop name it reads. `isArrayExprDirectPropRef` (`jsx-to-ir.ts`) is what
- * sets `isPropDerivedArray` in the first place, and it only recognizes two
- * shapes — a bare destructured-prop identifier (`entries.map(...)` inside
- * `function({ entries })`) or a direct `props.<name>` member access — so
- * unlike `findBaseSignalGetter` there is no `call`/chain walking to do; the
- * compiler already restricted the shape. Returns the prop's LOCAL binding
- * name; the caller resolves it to the CALLER-FACING field
- * (`sourceName ?? name`) via `propsParams`, matching how
- * `generateInputStruct`/`generateNewPropsFunction` key the Go field and how
- * `buildGoPropsInit` keys the harness's own prop initializer (both by the
- * JS `props` object's key, not the local destructure binding).
+ * sets `isPropDerivedArray` in the first place, and — even after #2724
+ * taught it to resolve a bare `const x = y` alias-hop chain (including one
+ * that reaches the WHOLE props object, e.g. `const p = props; p.items`) —
+ * `arrayParsed` (this function's input) is `loop.array`'s own written
+ * structure, not the alias-resolved origin: a hop through a destructured
+ * prop's alias ends up here as a bare identifier (the LOCAL alias name, not
+ * the prop's own name — resolved below via `propsParams`), and a hop that
+ * lands on `props.<key>` OR `<aliasOfProps>.<key>` both end up here as the
+ * same member shape (`.property` is the source key either way; this
+ * function never inspects `.object.name`, so it doesn't matter whether the
+ * object identifier IS `props` or an alias of it).
+ *
+ * `renderLoop`'s own BF101 gate (`go-template-adapter.ts`, the
+ * `arrayName`/`localConstants` check) refuses a BARE-IDENTIFIER loop array
+ * that is a local computed value — including an alias-hop identifier —
+ * before this function would ever see one for that shape. But that gate's
+ * `arrayName` regex (`^[A-Za-z_$][\w$]*$`) never matches a MEMBER-ACCESS
+ * array text at all, so a `<propsAlias>.<key>` loop array (unlike a bare
+ * identifier one) is NOT screened by BF101 and can reach this function for
+ * real — which is fine: the member branch below resolves it correctly
+ * regardless, per the previous paragraph. Unlike `findBaseSignalGetter`
+ * there is no `call`/chain walking to do here either way — whatever hop
+ * resolution happened, already happened in `isArrayExprDirectPropRef`.
+ * Returns the prop's LOCAL binding name; the caller resolves it to the
+ * CALLER-FACING field (`sourceName ?? name`) via `propsParams`, matching
+ * how `generateInputStruct`/`generateNewPropsFunction` key the Go field and
+ * how `buildGoPropsInit` keys the harness's own prop initializer (both by
+ * the JS `props` object's key, not the local destructure binding).
  */
 function findLoopPropField(expr: ParsedExpr | undefined): string | null {
   if (!expr) return null