Migrating from parsers to template files

important

Previously, Code Connect required framework-specific parsers for React, iOS, Android and Web Components. We introduced a new template API that removed framework requirements and allows users to more flexibly control how code snippets are rendered inside of Figma. Going forward, new users should opt for this template format and we recommend existing users to follow the below migration guide to move to the new format. Following August 17th, 2026, we will no longer be updating or actively maintaining the legacy parsers.

This guide explains some new changes to how users should write Code Connect files moving forward and how to migrate to our template file format.

Code Connect will no longer support framework-specific parsers

Previously, Code Connect was built on an early design decision: treat your Code Connect file as a string rather than executing it. This made type checking and IDE tooling possible, but it also introduced hard constraints that were difficult to work around.

Because Code Connect files weren't executed as code inside of Figma, conditional logic such as ternaries and switches were included in the output verbatim rather than evaluated when an instance was selected. For example, features like basic string manipulation also weren't possible with Code connect. While we improved the original Code Connect API to support these cases, there were still many edge cases around what code was considered valid to use in Code Connect.

The new template API and files work differently. Your template is a function that runs and returns a string, which means you write it the way you'd write any other code – using conditionals, string interpolation, and arbitrarily complex logic. This new format also made Figma data available as inputs. Basically, anything that's valid JavaScript or TypeScript is valid in your template. This approach also means Code Connect works the same way no matter which framework your design system is built with.

The result is a setup that's simpler to learn, easier to reason about, and more capable than what parsers made possible. The migration path is designed to be as low-effort as possible, and the output in Figma will be identical to what you have today.

Why you should migrate

We generally recommend all users to migrate to template files as they’re easier to write and maintain than parser-based Code Connect. If you’re currently maintaining Code Connect files or planning to write new ones, it’s particularly worth migrating to template files first. Template files will also receive updates and support over time, such as incompatibility or security issues. The migrate command documented below is designed to deterministically convert your files and is the quickest way of migrating your Code Connect.

While we recommend migrating ahead of August 17th, 2026, parsers will remain available via older versions of Code Connect CLI, so you're also free to migrate at a later date.

Migrating Code Connect files with the migrate command

We recognize that many users have spent a fair amount of time building their Code Connect documentation. To help, the Code Connect CLI now offers a migration command to deterministically convert your existing Code Connect files to the new template files format. The command works by first parsing your whole project for Code Connect objects, then saving those objects as template files (.figma.ts). While these new files are a different format to your original Code Connect, the output in Figma and in MCP will be the same. Once you’re happy with the result, you can publish these to Figma and delete your old Code Connect files.

tip

If your organization doesn’t allow TypeScript and needs JavaScript outputs instead, pass the --javascript flag when running the migration tool.

npx figma connect migrate [options]

Options:

• --outDir <dir> — write template files to a specific directory instead of alongside the source files
• --javascript — output .figma.js files instead of the default .figma.ts
• --delete — delete source Code Connect files after they are successfully migrated
• --include-props — preserve __props metadata blocks in the migrated output. By default these are removed, since they are an implementation detail of parser-based files and are not needed in template files. Pass this flag if using the React .getProps() or .render() modifiers, or if you have other template files that read executeTemplate().metadata.__props from the migrated components.

Migrated files

It’s important to treat the migration output as a starting point rather than production-ready Code Connect. The files will render correctly, but there are usually opportunities to simplify them, ex: removing unnecessary helpers, cleaning up redundant props, and restructuring variant logic. See the sections below for the most common areas to review.

Migrated template files make use of figma.helpers to ensure correct rendering of code. If you know exactly how your code should appear, it may be simpler to remove some of these. For example, if you're rendering a required prop in React that is always of a known type, then this code:

figma.code`<Counter${figma.helpers.react.renderProp('count', count)} />`

Can be simplified to:

figma.code`<Counter count={${count}} />`

Variant restrictions

Components that used variant restrictions in the legacy CLI (multiple figma.connect calls pointing to the same Figma URL with different variant objects) are migrated into a single file with an if/else-if/else branching structure. For example:

// Migration output
let template
if (figma.selectedInstance.getPropertyValue('Has Label') === 'true') {
  template = {
    example: figma.code`<InputField label={${label}} />`,
    imports: ['import { InputField } from "./InputField"'],
    id: 'input-field',
  }
} else {
  template = {
    example: figma.code`<Input />`,
    imports: ['import { Input } from "./Input"'],
    id: 'input',
  }
}

export default template

This structure works but is verbose and requires more manual review than other migration output. In most cases it can be simplified using getBoolean(), getEnum(), or standard conditional logic:

// Cleaned up
const hasLabel = figma.selectedInstance.getBoolean('Has Label')

export default {
  example: hasLabel
    ? figma.code`<InputField label={${label}} />`
    : figma.code`<Input />`,
  imports: hasLabel
    ? ['import { InputField } from "./InputField"']
    : ['import { Input } from "./Input"'],
  id: 'input',
}

When reviewing migrated variant files, pay particular attention to:

• Conditions using getPropertyValue(): these are a direct translation of the original variant restrictions and can usually be replaced with typed methods like getBoolean() or getEnum().
• One Figma component mapping to multiple code components: when different property values should render entirely different components (as in the example above), the cleaned-up version often uses a ternary or early return rather than a full if/else block.
• Multiple variant properties AND'd together: the migration generates getPropertyValue('A') === 'x' && getPropertyValue('B') === 'y' conditions. These can often be simplified or collapsed using getEnum() with a mapping object.

Testing in Figma

For testing out these changes in Figma, you will need to set up your figma.config.json. We recommend setting label to a temporary value so you can easily publish / unpublish without affecting your existing Code Connect, and limiting include to only publish the new files. See Configuring your project for more details on these values.

{
  "include": ["**/*.figma.ts"],
  "label": "TEST",
  "language": "jsx"
}

You can then publish under your temporary label to test these out in Figma :

npx figma connect publish --config <your figma.config.json path>

When you're done, you can remove these from Figma with unpublish:

npx figma connect unpublish --config <your figma.config.json path>

Using the MCP skill to create template files

If you are using the Figma plugin with an approved MCP Client, you can use the built-in Code Connect skill to create template files from a Figma URL. The agent will inspect the component's properties, find the matching code component in your project, and write the .figma.ts file for you.

Prerequisites

• Claude Code with the Figma plugin installed
• A Figma component published to a team library
• An Organization or Enterprise Figma plan

Usage

Paste a Figma component URL into Claude Code and ask it to create a Code Connect template:

Create a Code Connect template for https://www.figma.com/design/abc123/MyDS?node-id=42-100

Alternatively, you can invoke the skill directly:

/figma-code-connect (url: https://www.figma.com/design/abc123/MyDS?node-id=42-100)

Claude will:

1. Identify the published component at that URL
2. Fetch its property definitions from Figma
3. Find the matching component in your codebase
4. Confirm the match with you before writing anything
5. Create a .figma.ts file alongside your existing Code Connect files

Review the output

As a reminder, treat the generated file as a starting point. It’s worth checking for example that the mapping between Figma properties and your code properties makes sense. See Writing template files for details on the template format and API.

Publish

Once you're happy with the file, publish it to Figma:

npx figma connect publish

Finishing up

Once you’ve fully migrated your Code Connect files into templates, you can now delete any remaining parser-based Code Connect files (e.g. *.figma.tsx files if using the React parser).

You can also remove any parser-specific fields from figma.config.json. These are:

• parser
• importPaths (React only)
• paths (React only)
• imports (React only)
• xcodeprojPath (SwiftUI only)
• sourcePackagesPath (SwiftUI only)
• importMapping (SwiftUI only)