fix: resolve variable collection by key when cross-file ID lookup fails#3888
fix: resolve variable collection by key when cross-file ID lookup fails#3888akshay-gupta7 wants to merge 2 commits into
Conversation
|
|
|
There was a problem hiding this comment.
Pull request overview
This PR improves swapFigmaModes in the plugin sandbox so that applying an active theme can still “Swap Figma modes” when the stored $figmaCollectionId cannot be resolved in the current file (e.g., when using a $themes.json created in a different file and consuming variables from a subscribed library).
Changes:
- Adds a fallback resolution strategy when
getVariableCollectionByIdAsync($figmaCollectionId)returnsnull. - Attempts to resolve the collection (and mode) via a stable variable key from
$figmaVariableReferencesusingimportVariableByKeyAsync.
| if (!resolvedCollection) { | ||
| // Fallback: the stored ID is from a different file (e.g. a published library used in a consumer file, | ||
| // or a collection that was deleted and recreated). Try to resolve via a variable key from | ||
| // $figmaVariableReferences — variable keys are stable across files. | ||
| const variableKey = Object.values(themeObject.$figmaVariableReferences ?? {})[0]; | ||
| if (variableKey) { | ||
| try { | ||
| const importedVariable = await figma.variables.importVariableByKeyAsync(variableKey); | ||
| if (importedVariable) { |
|
Commit SHA:3368a994a4de710d3f64ec9a2bdb6a107e903a25 Test coverage results 🧪
|
|
🛡️ Hyma Compliance Check
Full finding details[ROPA]
|
|
🛡️ Hyma Compliance Check ✅ No compliance-relevant changes detected 1 file(s) scanned · 0 findings
|
|
🛡️ Hyma Compliance Check ✅ No compliance-relevant changes detected Files scanned · 0 findings No new external calls, personal data processing changes, or authentication/authorization modifications detected. No compliance action required.
|
|
🛡️ Hyma Compliance Check ✅ No compliance-relevant changes detected 2 file(s) scanned · 0 findings
|
Why does this PR exist?
Closes #0000
When a
$themes.jsonis used in a different Figma file than where it was created (e.g. a consumer file subscribed to a published library), applying an active theme with "Swap Figma modes" enabled fails with:$figmaCollectionIdis scoped to the file it was created in. In any other file,getVariableCollectionByIdAsyncreturns null and the mode swap is skipped entirely.What does this pull request do?
Adds a fallback in
swapFigmaModesfor when the stored collection ID can't be resolved. It takes the first variable key from$figmaVariableReferences, callsimportVariableByKeyAsyncto resolve it in the current file, and derives the correct collection and mode from the result. Variable keys are stable across files, so this works for subscribed library collections.The error toast is preserved for cases where the fallback also fails (e.g. the library is not subscribed, or
$figmaVariableReferencesis empty).Testing this change
$figmaCollectionIdand$figmaVariableReferencesin$themes.json$themes.jsoninto the plugin in file BBefore: error toast fires, mode is not swapped
After: mode swaps silently
Additional Notes (if any)
The fallback requires
$figmaVariableReferencesto be populated. If a theme has no variable references stored (i.e. "Export to Figma" was never run), the fallback cannot resolve the collection and the error toast still appears. Users in that state need to run "Export to Figma" in the source file first.