Import build reference
Supported Build Recipes
Build recipes define how Vibecodr turns imported project source into browser-ready runtime output.
Build recipe reference for user-authored Vibecodr imports.
Implementation focus
Use this reference when preparing repository structure, checking recipe detection, or fixing a project that imports but does not build.
Expected outcomes
- Understand the supported recipe ids and expected outputs.
- Separate framework detection from the recipe that runs the build.
- Use supported package managers for build-backed imports.
- Fix unknown or unsupported project shapes without weakening runtime safety.
Recipe is the build lane
A build recipe tells Vibecodr how a project becomes browser-ready runtime output. Framework detection can help explain what was found, but `recipeId` is the public build-lane fact that matters during import and build decisions.
The supported recipe set is intentionally small and explicit. Vibecodr accepts harmless project variation at the edge, then normalizes into one recipe before running policy, build, and publish behavior.
- `static` is for browser-ready files that do not need a package build.
- `vite` is for Vite-style browser builds that usually write `dist`.
- `astro` is for static Astro output that writes `dist`.
- `next-static` is for Next static export output that writes `out`.
- `sveltekit-static` is for SvelteKit static output that writes `build`.
- `unknown` means Vibecodr could not safely choose a supported recipe.
Supported package managers
Build-backed imports currently expect `npm` or `pnpm`. Lockfiles and package metadata help Vibecodr choose a repeatable install/build path. Unsupported package managers are detected so the user can change the project instead of getting a partial, unreliable build.
Static projects do not need dependency installation when the archive already contains browser-ready files. If a project needs dependencies to become runnable, it should use a supported build recipe rather than relying on local machine state.
- Use `package.json` scripts that produce a static browser output directory.
- Next static projects should be configured for static export and produce `out`.
- SvelteKit static projects should use static adapter output that produces `build`.
- If a supported build writes somewhere else, set `build.outputDir` in `vibecodr.json` to the verified browser-ready directory.
- Keep the build deterministic enough that a fresh install can reproduce it.
- Do not depend on files outside the uploaded ZIP or selected repository.
Recipe failures are user-actionable
A recipe failure should point to the project fact that could not be safely understood: no entry file, unsupported package manager, missing build command, missing output directory, or a framework that needs a different export mode.
Do not treat a recipe failure as permission to loosen the runtime boundary. The fix is to make the project output browser-ready files that Vibecodr can verify and publish.
- If the detected framework is right but the recipe is `unknown`, check the build script and output directory.
- If the recipe is right but playback fails, move to troubleshooting for published artifact playback.
- If source includes secrets, remove them before importing again.
Example and read next
Example: your repository has both React code and a package file. Check whether Vibecodr normalized it to static, vite, astro, next-static, or sveltekit-static before assuming a framework label is the build lane.
Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.
- Read next: Import a Project
- Read next: Studio
- Read next: Dependency Determinism
- Read next: Troubleshooting