Importing components

What the Workbench checks before a component can be published.

The Workbench never rewrites your source. It reads it, reports what it finds, and lets you decide.

What is analysed

• Imports — npm packages (including scoped ones), @/ and relative imports, and imports that resolve to another component of this registry.
• Assets — images, video, fonts and url() references, classified as local, remote or missing.
• CSS — stylesheets, CSS variables, keyframes and classes that are not Tailwind utilities.
• Tailwind — custom animations, theme tokens and plugins the component expects.
• Quality — leftover TODOs, debug console.log, identifiers used but never imported.

What blocks publishing

• a syntax error;
• a component that is not TypeScript (.jsx / .js files): type the props and save it as .tsx;
• no exported React component;
• an npm package that is not installed in this project;
• a local import that cannot be resolved;
• a registry dependency that is not published;
• a duplicate slug, name or file path;
• a missing local asset, until you explicitly accept it;
• a failed sandbox compilation.

Everything else is a warning.

Examples

A component can carry one or more examples: snippets that use it. An example becomes the preview and is shown as Usage on the component page; it is not part of what gets installed.

• Add example in the Workbench, then paste the snippet. Its import can stay exactly as it is in the project it came from — it is matched to the component.
• If you paste a page that only uses a component, the analysis offers to keep it as the example and opens an empty file for the component itself.

Multi-file components

Add secondary files in the Workbench with Add file. When an import is missing, the report shows the path it expects and an Add this file button. If you pasted a page that only uses a component, paste the component’s own source instead. Relative imports between the files of a component are resolved together, and CSS files are bundled into the preview.