Render: instance-swap prop configurations fall back to the component default

[nathanacurtis]

Problem

When a spec configures an instance-swap property — an icon on an avatar, for example — render does not apply it. The instance keeps whatever its component defaults to, so a component specified with one icon renders with another.

Background

Instance-swap values in a spec are component names. Figma's setProperties expects a published component key. Passing the name is rejected, so the configuration is currently skipped and reported:

⚠ [writer] propConfig "Avatar.icon": instance-swap properties take a component key, not a name — skipping

Skipping is deliberate — it was previously throwing and taking every other property on that instance down with it (fixed in #291) — but it leaves the configured value unapplied.

Solution

Resolve the configured name to a component key before applying it, using the manifests render already carries for this purpose:

• instanceIdManifest — spec key to component reference
• glyphIdManifest — glyph content name to component reference, which is how icons resolve elsewhere in the writer
• InstanceElement.resolveEntry — same-file node id first, published-key import when the component lives in another file

Report and skip only when the name resolves to nothing.

Acceptance criteria

• A spec configuring an instance-swap prop renders with the configured component, not the default
• Icons resolve through the glyph manifest, including icons that live in a separate library file
• An unresolvable name is reported clearly and skips that property alone
• Round-trip diffs show instance-swap propConfigurations surviving

Fixtures

AvatarGroup — Avatar.icon is the live example

Subtask of #204.

[nathanacurtis]

Fixed in figma-from-specs 2dd545f and specs-cli 6baa688 (both on feat/figma-from-specs).

One correction to the issue's premise: setProperties does not want a published component key for an instance swap. The Plugin API documents the value as the component's node id ('1:24'), and addComponentProperty(name, 'INSTANCE_SWAP', '2:22') likewise. That is what InstanceElement.resolveEntry already returns — importing by key when the component lives in another file, which makes its id local — so no new machinery was needed on the write side.

What changed

• Configured names resolve through both manifests: catalogue components by spec key, icons by matching the glyph manifest's raw names in formatted space. Icons in a separate library file resolve through the published-key import.
• The bridge now offers prop configuration values to the library-name fallback it already applied to instanceOf, including $nested configs. Without that, a swap naming a component the workspace has no spec for could not resolve — it was the single remaining unresolved reference in the reference catalogue (egdsAssetMarkGoogle).
• An unresolvable name reports and skips that property alone, leaving the rest of the batch to apply.

Verification

Across the 69-component reference catalogue: zero instance-swap properties take a component key refusals, and zero unresolved swap names. propConfigurations survive the round trip — name: settings on a nested icon comes back intact.

The propConfig warnings that remain are different defects, not this one: VARIANT takes a string (a spec carrying a boolean where the Figma variant expects "True"/"False", 52 occurrences) and no matching property on instance (mostly ADR-063 image props).