Visual Components normally generate typed React/TSX plus a CSS Module. Depending on the design, the module can export Props, DefaultProps, States, Variants, Children, and Component; project features can add runtime, asset, data, document, route, or backend output.
Read the exact export-output reference.
It can, when the consumer supports the generated imports, TSX, SCSS/CSS Modules, assets, client boundaries, and runtime dependencies. Treat the consumer's clean install, typecheck, tests, build, and rendered behavior as the compatibility proof.
Do not rely on a permanent version matrix in these docs. Inspect the actual generated imports and the selected boilerplate or consumer package, then build that combination. Output can change when project features add data, timelines, documents, or other runtime helpers.
Check dependencies and compatibility.
Generated design properties are normally passed through a nested properties object, while variants and named child slots have separate generated contracts. Inspect the emitted type exports instead of assuming a conventional flat-prop API.
No as a durable extension strategy. Export can replace generator-owned files. Keep adapters, wrappers, application logic, tests, and hand-authored extensions outside the generated boundary; after re-export, inspect the complete diff and rerun the consumer gates.
Use code inspection when you need to study a selected file, but the current local-folder export operation writes whole-project output to every configured local target. It is not a selected-Component deployment action.
Only when its job matches your destination. Website, npm-package, backend, Cloudflare, and Vercel starters are distinct shells and are not equally complete. An existing application with a clear generated boundary may be the better integration target.
No. Its current public state contains project-specific and incomplete package/build assumptions. Review and repair its package identity, entry maps, source/output paths, dependencies, declarations, and consumer verification before publication.
Read the npm-package boilerplate limitations.
At minimum: no unexpected diff, no secret leakage, a clean dependency install, typecheck, tests, production build, expected assets and entry points, and a rendered smoke test of affected states. Add API/backend/provider checks whenever the generated feature set uses them.