Documents
Welcome
Introducing
Why Misaki Studio
Compare
Start Here
Learn
Workflows
Export & Ship
AI & MCP
Questions & Answers
Reference
Project interface reference
File types
Element types
Design properties
Keyboard shortcuts
MCP capabilities
Export output reference
Dependencies and compatibility
Browser versus desktop
Current limitations
Troubleshooting
Examples

Dependencies and compatibility

Generated output is React/TypeScript with CSS Modules/SCSS and feature-driven runtime imports. Compatibility is proven by the output's actual imports plus a build in the intended consumer—not by a permanent version table in documentation.

Baseline consumer capabilities

A typical visual export needs:

  • React and React DOM compatible with the generated source;

  • TypeScript/TSX processing;

  • .module.scss and Sass support;

  • the misaki-studio-internal runtime version compatible with the generated API;

  • browser execution for modules marked "use client";

  • asset/public path handling for generated images, fonts, and media.

Feature use can add routing, API, Storage, Content, database-client, Document, rich-text, animation, design-system, or other imports. The current generated files are the dependency inventory.

React and Next.js integration

Generated Components are imported through their actual Component and typed contract exports. Generated Pages follow the current Page generator's route/default-export assumptions. In Next.js, account for the client boundary and the application's routing mode rather than moving generated files into an arbitrary route directory.

Use a handwritten adapter when the application's props, routing, providers, data layer, or server/client boundary differs from the generated contract.

Boilerplate compatibility

Boilerplates are starting shells, not proof of compatibility. Before adoption:

  1. inspect the repository's current package.json, lockfile, README, and build scripts;

  2. compare dependency names/APIs with generated imports;

  3. update in a branch and perform a clean install;

  4. run TypeScript, tests, production build, and local Preview;

  5. verify provider-specific static/server behavior.

Some public boilerplates are explicitly unfinished or older than the current runtime. See Choose a boilerplate.

Data and runtime compatibility

  • API output needs valid environment values, browser CORS/cookie policy, and safe secret placement.

  • Storage persistence is browser-origin/profile specific.

  • Content is public/export-time data.

  • Database/auth features require a verified backend; current action execution and sensitive Users export boundaries are unfinished.

  • Document Page routes and rich output need verification in the selected website shell.

  • External media hosts control availability, CORS, and video range requests.

How to verify an upgrade

  1. Export into a clean/versioned generated boundary.

  2. Diff imports, public types, generated runtime calls, and asset paths.

  3. Reconcile package versions through the consumer's package manager.

  4. Build from a clean dependency state.

  5. Exercise responsive, variant, interaction, animation, and data paths.

  6. Re-export once to confirm the boundary remains repeatable.

Do not edit generated source to paper over a version mismatch; fix the Misaki project, runtime package, adapter, or consumer configuration that owns it.

On this page
Dependencies and compatibility
Baseline consumer capabilities
React and Next.js integration
Boilerplate compatibility
Data and runtime compatibility
How to verify an upgrade