Describe the bug
When exporting components using the React Export plugin / unframer CLI, type extraction fails for many components with SyntaxError
This occurs repeatedly during the "Extracting types for component: ..." phase. The CLI continues running, successfully generates the .js files (containing the component JSX code) and styles.css, but no matching .d.ts type files are created for the affected components (often most or all of them in the project).
Runtime rendering of the exported .js components still works (they can be imported and displayed in Next.js/React apps), but full TypeScript support (prop types, IntelliSense, type checking) is lost for those components.
Steps to reproduce
- Open a Framer project that includes components with features such as forms, navigation, pricing blocks, testimonials carousels, accordions, or any logic that might involve internal data/query handling.
- Install and open the React Export plugin in Framer → select multiple components (or all) for export.
- Publish the Framer project (required for the CLI to fetch the latest bundles).
- In a Next.js (or other React) project, run the CLI command provided by the plugin, e.g.:
- Observe the output: type extraction fails for numerous components with errors like:
The same error repeats across different chunks (chunk-NTCJV3I6.js, chunk-L32L4AZN.js, etc.) and components (navigation, pricing-block, footer, cta-block, team-card, animated-backgrounds, contact-form, logo, etc.).
- The process ends with "Build completed" and "✓ Your components are exported to framer folder", but only
.js files are present — missing .d.ts for the failed ones.
Expected behavior
Type extraction should complete successfully for all components, generating .d.ts files with prop types inferred from propertyControls (as described in the README), providing full TypeScript support including IntelliSense and type checking when using the components in .tsx files.
Actual behavior
.js component files and styles.css are correctly generated → components can be imported and rendered at runtime.
- No
.d.ts files are created for components that trigger the queryCache import error.
- In VS Code / TypeScript projects: no prop type hints, no type checking, frequent "Property does not exist" warnings when passing props (even though runtime works).
Environment
- OS: Windows
- Node.js: v22.16.0
- unframer version: [please run
npx unframer --version and paste the output here before submitting]
- React in target project: 19.x (installed via create-next-app@latest)
- Framer project: Landing page with many interactive components (forms, navigation, pricing, testimonials carousel, accordions, animated illustrations, etc.)
- Framer runtime / plugin: Latest as of December 31, 2025
- Additional steps already tried:
- Manual install of missing packages (
canvas-confetti@^1.4.0, react-simple-typewriter, @motionone/dom@^10.13.1)
- Re-publishing in Framer
- Disabling React Strict Mode
- Re-running export multiple times
Additional context
The failing imports appear in shared chunk files (e.g. chunk-DA5HFLL2.js, chunk-NTCJV3I6.js, chunk-L32L4AZN.js), suggesting queryCache is part of Framer's internal runtime for data/query-related features.
This seems to be caused by a recent change in Framer's runtime where queryCache was removed, renamed, or is no longer exported from the "unframer" module — breaking unframer's Node.js-based type analysis step.
The README describes type extraction as running the components in Node.js and pulling from propertyControls, but this fails when the imported runtime code contains invalid named exports.
Runtime usage still works fine — just no TypeScript types.
Happy to provide:
- Full CLI log
- Sample component code
- Framer project access (if private sharing is possible)
Thank you for this awesome tool — it would be perfect with this fixed!
Describe the bug
When exporting components using the React Export plugin / unframer CLI, type extraction fails for many components with SyntaxError
This occurs repeatedly during the "Extracting types for component: ..." phase. The CLI continues running, successfully generates the
.jsfiles (containing the component JSX code) andstyles.css, but no matching.d.tstype files are created for the affected components (often most or all of them in the project).Runtime rendering of the exported
.jscomponents still works (they can be imported and displayed in Next.js/React apps), but full TypeScript support (prop types, IntelliSense, type checking) is lost for those components.Steps to reproduce
The same error repeats across different chunks (
chunk-NTCJV3I6.js,chunk-L32L4AZN.js, etc.) and components (navigation, pricing-block, footer, cta-block, team-card, animated-backgrounds, contact-form, logo, etc.)..jsfiles are present — missing.d.tsfor the failed ones.Expected behavior
Type extraction should complete successfully for all components, generating
.d.tsfiles with prop types inferred frompropertyControls(as described in the README), providing full TypeScript support including IntelliSense and type checking when using the components in.tsxfiles.Actual behavior
.jscomponent files andstyles.cssare correctly generated → components can be imported and rendered at runtime..d.tsfiles are created for components that trigger thequeryCacheimport error.Environment
npx unframer --versionand paste the output here before submitting]canvas-confetti@^1.4.0,react-simple-typewriter,@motionone/dom@^10.13.1)Additional context
The failing imports appear in shared chunk files (e.g.
chunk-DA5HFLL2.js,chunk-NTCJV3I6.js,chunk-L32L4AZN.js), suggestingqueryCacheis part of Framer's internal runtime for data/query-related features.This seems to be caused by a recent change in Framer's runtime where
queryCachewas removed, renamed, or is no longer exported from the"unframer"module — breaking unframer's Node.js-based type analysis step.The README describes type extraction as running the components in Node.js and pulling from
propertyControls, but this fails when the imported runtime code contains invalid named exports.Runtime usage still works fine — just no TypeScript types.
Happy to provide:
Thank you for this awesome tool — it would be perfect with this fixed!