Reader: a code-only prop colliding with a native property name is silently dropped

[nathanacurtis]

A code-only prop whose name matches a native component property is dropped, and the spec ends up describing neither of them fully.

Code-only prop "Value" conflicts with native prop — skipping

Seen on a text input during a full-catalogue generate: the component carries a native TEXT property Value and a code-only prop of the same name in its hidden container. The native one wins, the code-only one is discarded, and everything the code-only prop carried — its type, its examples, and the $extensions['com.figma'].source provenance recording that it is code-only — is gone.

Why it is worth more than a warning

• The prop disappears from the spec. A consumer generating an API surface never learns it exists.
• It cannot round-trip. Render rebuilds code-only props from that provenance; with nothing recorded, a rendered component is missing the hidden layer the source has, and the next read of it is silent about the loss.
• The warning is easy to miss. It prints mid-progress in a 66-component run, and the generate still reports success.

The question to settle

The current rule is first-wins-by-name, which is a decision made by accident of ordering rather than intent. Options worth weighing:

• Emit both, distinguishing them — the code-only one already carries provenance that says what it is, so the two are not actually ambiguous in the data, only in the key.
• Keep the collision but make it loud — a spec that silently omits a prop is worse than one that reports a conflict as an error a designer can fix by renaming.
• Prefer neither and fail the component, on the grounds that a component with two props of one name is a design defect in the file rather than something the reader should paper over.

Whichever is chosen, the outcome should be visible in the spec rather than only in a line of console output.

Where

specs-from-figma/src/Component/Props/CodeOnlyProps/CodeOnlyProps.ts:85 — if (propName in existingProps), which skips and warns.

[nathanacurtis]

Out of scope for launch — this arises only from VARIANT-based code-only props, which are not in the launch scope. Removed from the Fidelity list on the render command page; the issue stays open in the backlog.

Recording what the investigation found, so whoever picks this up does not start from zero:

The two props are genuinely distinct. The native Value#23:31 is a TEXT property holding the displayed text. The colliding one is not a property of the component at all — it is a hidden layer, an INSTANCE named String value inside the Code only props frame, whose picker component set declares a single variant property named Value with options Text | Email | Number | Phone number.

The collision is therefore a naming-source question, not a precedence question. InstanceCodeOnlyProp.extract names the prop from the picker's internal variant key (propName = key.split('#')[0]) rather than from the layer the designer placed and named. Reading the layer name instead would yield stringValue and no collision would exist. That is worth weighing before any first-wins/emit-both/fail policy is designed, since it may remove the problem rather than resolve it.

Note the two sources disagree elsewhere: the layer Interaction sits inside a picker whose variant key is Button input, and today's spec emits buttonInput. Changing the naming source would change that spelling too.

[nathanacurtis]

Related: #350 tracks the round-trip losses on this same class of prop — provenance (source.instanceOf) and Figma type (VARIANT reading back as BOOLEAN). Both are out of scope for launch, and a fix for either should be weighed against the other, since renaming the source would touch the same extraction path.