How Do You Migrate from DevLink Sync to DevLink Export in Webflow?

Webflow CLI v1.19.0 shipped the new webflow devlink export command on April 28, 2026. The command generates a static, self-contained DevLink bundle of Webflow components as local React code that runs without a build-time connection to Webflow. The April 29 follow-up made JSX the default file extension and updated cloud init scaffolds for Astro and Next.js. I have migrated three Phoenix Studio retainer Webflow Cloud projects from DevLink Sync to Export between April 28 and today. The most fragile step is the Runtime Props plus DevLink Slots Designer-side migration, and that is where this tutorial earns its keep. In this piece I walk through the migration end to end, from CLI bump to webflow.json restructure to the Designer-side work.

What is DevLink Export and why did Webflow ship it?

DevLink Export is a Webflow CLI command introduced in v1.19.0 on April 28, 2026. The command generates a static, self-contained DevLink bundle of Webflow components as local React code, packaged so the resulting bundle runs in any React project without a build-time connection to Webflow. The previous DevLink Sync command required Webflow API connectivity during the build process.

The structural reason Webflow shipped Export is that DevLink Sync's build-time dependency on the Webflow API caused build failures whenever Webflow had an outage, an API rate limit was hit, or a CI environment lacked network access. Export decouples the React project from the Webflow build dependency. The components are generated once at sync time and committed to the React project's source tree. The piece I wrote on Webflow's May 13 Premium plan covered the broader Webflow platform context this migration sits inside.

How is DevLink Export different from DevLink Sync?

DevLink Sync fetches Webflow components at build time, generates React code, and writes it to a build directory. DevLink Export generates the same React code but writes it directly to a committed source directory in the project, with no build-time Webflow connection required. The runtime behavior of the generated components is identical. The difference is purely in when and where the code generation happens.

The practical implication for Phoenix Studio client projects is that DevLink Export bundles ship inside the project's Git history and run in any environment that can run React. The Webflow API is only consulted when explicitly running the export command to refresh components. CI builds, production deploys, and local development all work without Webflow connectivity. The build-time fragility that Sync introduced is fully eliminated.

When should you migrate an existing DevLink Sync project?

Migrate an existing DevLink Sync project to Export when the project ships to production, when the build process is sensitive to network outages, or when the CI environment cannot reach the Webflow API reliably. For prototype or single-developer projects that rebuild infrequently, the migration can wait. For client work that ships to production multiple times per week, the migration is worth doing this sprint.

For Phoenix Studio's three migrated retainer projects, the trigger was a single CI build failure caused by a Webflow API rate limit during a deploy window. The failure cost about 90 minutes of debugging before I realized the Sync dependency was the cause. The Export migration took about 2 hours per project and eliminated the failure mode entirely. The decision is straightforward once a project hits a real Sync-related build failure.

How do you bump Webflow CLI to v1.19.0 safely?

Bump Webflow CLI to v1.19.0 by running npm install at-webflow slash webflow-cli at the latest version inside the project directory, or globally if the CLI is installed globally. Verify the version with webflow --version after install. The new CLI maintains backward compatibility with the existing webflow devlink sync command, so existing scripts continue working until the migration is complete.

The safe migration pattern is to bump the CLI version, verify that webflow devlink sync still works in the current configuration, and then start the migration to webflow devlink export incrementally. The piece on Chrome 148 Prompt API covered a parallel platform-state migration where the same incremental discipline applied. Treat the CLI bump as a separate commit from the migration itself, so any issues are easier to isolate.

What changes inside webflow.json during migration?

The webflow.json file changes structure during the DevLink Sync to Export migration. The previous structure had a single block for component sync configuration. The new structure splits configuration into separate blocks for sync and export, with the export block specifying the output directory, the file extension default (JSX as of April 29), and any component filtering rules. Both blocks can coexist during transition.

The most important fields in the export block are outputDir, which specifies where the React components are written; ext, which defaults to jsx but can be overridden to tsx for TypeScript projects; and include and exclude patterns that filter which Webflow components are exported. The filtering patterns use regex syntax, which is more powerful than the previous configuration but requires testing. Verify that the expected components are exported before deleting the Sync configuration.

How do you handle Runtime Props in the Designer-side migration?

Runtime Props are the Designer-side configuration that lets DevLink components receive values from the consuming React project at render time. The migration to DevLink Export requires verifying that all Runtime Props are still wired correctly in the Designer after the export. Webflow's spec for Runtime Props is the same in Export as in Sync, but the export step is the moment to catch any Designer-side misconfiguration that the previous Sync flow may have masked.

For Phoenix Studio's three migrated projects, the most fragile case I encountered was a B2B SaaS landing page hero animation where a Runtime Prop controlled the animation duration. The Sync export had been masking a Designer-side prop type mismatch that surfaced as a TypeScript error on the Export. The fix was a one-line webflow.json adjustment plus a Designer-side prop type correction. The total fix time was 20 minutes once the cause was identified.

Why does cloud init now scaffold with DevLink Export by default?

The webflow cloud init command, updated on April 29, 2026, now scaffolds new Webflow Cloud projects with DevLink Export as the default configuration. The scaffold updates apply to Astro, Next.js, and other supported React frameworks. The change reflects Webflow's recommendation that new projects start on Export rather than migrate from Sync later.

For Phoenix Studio's new client projects, the practical implication is that the default scaffold produces a project structure that does not need migration. Existing projects scaffolded before April 29 will need the migration covered in this tutorial. The default change also signals Webflow's commitment to Export as the long-term direction. The piece on Webflow well-known files covered another platform-state update from the same week.

Does TypeScript or JavaScript output matter for new projects?

For new Webflow Cloud projects, the choice between TypeScript (.tsx) and JavaScript (.jsx) output for DevLink Export depends on the host project's existing TypeScript configuration. Projects with TypeScript already configured benefit from .tsx output because the Webflow component types integrate with the project's type-checking layer. Projects without TypeScript can stay on the .jsx default without losing functionality.

The change from .ts default to .jsx default on April 29 was made because most Webflow developers were scaffolding new projects without TypeScript, and the .ts default created friction in those cases. For developers who do want TypeScript, the override is a single config line in webflow.json. The Phoenix Studio pattern is to use .tsx for client projects with TypeScript already configured and .jsx for everything else.

How do you filter component exports using regex in webflow.json?

Filter component exports using regex patterns in the include and exclude blocks of webflow.json. The patterns match against component names defined in the Webflow Designer. A typical pattern excludes utility components and component variants that are not consumed in the React project, reducing the size of the exported bundle. The regex syntax is standard JavaScript regex.

For Phoenix Studio's typical client project, the regex pattern excludes any component whose Designer name starts with an underscore (the convention I use for internal-only components) and includes everything else. The exclude pattern is a simple caret underscore regex inside the webflow.json exclude block. The result is a cleaner exported bundle that only contains the components the React project actually consumes. The reduction is meaningful for projects with deep component hierarchies.

When can you safely delete the old DevLink Sync command?

You can safely delete the old DevLink Sync command from package.json scripts and CI configuration once the Export migration has been verified across local development, CI builds, and production deploys. The verification typically takes one or two deploy cycles to confirm that no Sync-dependent behavior was missed. After that, the Sync command is dead code that should be removed for cleanliness.

For Phoenix Studio's three migrated projects, the Sync command was removed approximately one week after the Export migration was complete. The week of overlap caught one Runtime Props issue that would have shipped to production otherwise. The discipline is to keep the Sync configuration as a fallback for the first deploy cycle, verify the new Export-based flow, and then commit to the Export-only state. The migration is reversible during the overlap and final after the cleanup.

If you are migrating a Webflow Cloud project from DevLink Sync to Export and want to talk through the Runtime Props migration step for your specific component setup, drop me a line and tell me which React framework your project uses. I will share the webflow.json restructure pattern I am running on Phoenix Studio's retainer projects this sprint. Let's chat.