Instructing Lovable to Use Specific Frameworks or Libraries

Paste one of the ready-to-use Lovable prompts below into your Lovable chat. Each prompt tells Lovable exactly which files to change, what to add to package.json, and where to put secrets (via the Lovable Secrets UI) so Lovable can implement framework/library choices without asking you to run terminal commands.

 

Pasteable Lovable prompts

 

• Set framework and core libraries for a new project (React + TypeScript + Vite) — paste into Lovable:

// Project preference: use React + TypeScript + Vite as the app framework and bundler.
// Make explicit edits to files and package.json so the repo reflects this choice.
// Files to create/update:
//  - package.json: set name, scripts, and dependencies for react, react-dom, vite, typescript.
//  - tsconfig.json: add a basic TS config.
//  - index.html and src/main.tsx: minimal Vite React entry.
//  - src/App.tsx: basic component with a <Routes> placeholder.
// Please perform exact file changes below.

// update package.json (create if missing)
{
  "name": "my-app",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "vite": "^5.0.0",
    "typescript": "^5.0.0",
    "@types/react": "^18.0.0",
    "@types/react-dom": "^18.0.0"
  }
}

// create tsconfig.json with a minimal config
// create index.html and src/main.tsx, src/App.tsx as Vite/React entry files
// update README.md to state: "Framework: React + TypeScript + Vite"

// Note: Do not attempt to run npm install here. Add these files and leave instructions in README
// for local/GitHub CI installation. If CI setup is desired, add .github/workflows/node-ci.yml.

 

• Add Supabase client and secrets to an existing JavaScript/TypeScript app — paste into Lovable:

// Add Supabase to the project and wire in secrets via Lovable's Secrets UI.
// Changes to make:
//  - package.json: add "supabase-js": "^2.0.0" to dependencies.
//  - create src/lib/supabase.ts with a standard Supabase client initializer.
//  - update src/pages/Login.tsx (or src/App.tsx if Login doesn't exist): import the client and show a simple auth usage comment.
//  - update README.md with instructions: "Set SUPABASE_URL and SUPABASE_KEY in Lovable Secrets."

// update package.json dependencies (merge with existing)
"dependencies": {
  // ...existing deps...
  "supabase-js": "^2.0.0"
}

// create src/lib/supabase.ts
// // Supabase client wrapper
import { createClient } from "@supabase/supabase-js";

const supabaseUrl = process.env.SUPABASE_URL;
const supabaseKey = process.env.SUPABASE_KEY;

export const supabase = createClient(supabaseUrl || "", supabaseKey || "");

// update src/pages/Login.tsx or src/App.tsx to import { supabase } from "../lib/supabase"
// and add a small example comment demonstrating signIn/signUp usage.

// Instruction for Secrets:
// In Lovable Cloud, open the Secrets UI and add two Secrets:
//  - SUPABASE_URL (value: your Supabase project URL)
//  - SUPABASE_KEY (value: your anon/public key)

 

• Swap routing library to React Router in an existing React app (edit specific files) — paste into Lovable:

// Replace/enable React Router usage. Make direct edits as follows:
//  - package.json: add "react-router-dom": "^6.8.0" to dependencies.
//  - update src/main.tsx or src/index.tsx to wrap <App /> in BrowserRouter.
//  - update src/App.tsx: replace current route handling with <Routes> and <Route> components.
//  - update any file that referenced the old router to use react-router-dom's useNavigate/useParams as needed.

// update package.json dependencies
"dependencies": {
  // ...existing deps...
  "react-router-dom": "^6.8.0"
}

// update src/main.tsx (replace where App is rendered)
// // wrap App with BrowserRouter
import { BrowserRouter } from "react-router-dom";
import App from "./App";

root.render(
  <BrowserRouter>
    <App />
  </BrowserRouter>
);

// update src/App.tsx in the <Routes> block
// // Example Routes
import { Routes, Route } from "react-router-dom";
import Home from "./pages/Home";
import About from "./pages/About";

function App() {
  return (
    <Routes>
      <Route path="/" element={<Home />} />
      <Route path="/about" element={<About />} />
    </Routes>
  );
}

export default App;

 

• Major framework migration or anything that needs terminal (outside Lovable) — paste into Lovable:

// This migration requires running CLI commands (install/build/migrate). I want a Git-aware PR with changes plus a clear checklist for local or CI execution.
// Actions for Lovable:
//  - Create a branch named "migrate-next-to-vite" and modify files to reflect the target structure (package.json, tsconfig.json, vite config, src/*).
//  - Add .github/workflows/migrate-ci.yml that runs npm install and tests on push to this branch.
//  - Create README-MIGRATION.md with step-by-step commands the developer must run locally (marked "outside Lovable (terminal required)"), e.g. npm install, node scripts, etc.
// Do not attempt to run installs in Lovable; produce files and a migration checklist.

 

Extra notes (short)

 

• Secrets must be set via the Lovable Secrets UI — include that instruction in the prompt whenever a library needs keys.
• If a change needs a terminal, tell Lovable to create GitHub workflow files and a migration README labeled "outside Lovable (terminal required)".

The simplest, most reliable approach in Lovable is to record explicit framework preferences in repository files and in Lovable’s UI (Secrets) so the chat agent and reviewers always know the exact framework, version, package manager, build and dev commands, runtime (Node) version, and any SSR vs CSR expectations — then surface those in package.json and a small repo manifest so Lovable previews and exports behave predictably. Do this entirely with Chat Mode edits (create/update files), the Preview, and the Secrets UI; use GitHub sync/export only for actions that truly require a terminal.

 

Core best practices (short)

 

• Create a repo manifest (file the project can read) that lists framework, version, package manager, build/dev commands, ports, and SSR/CSR decision.
• Make package.json authoritative — add engines, explicit scripts, and a comment-like section in a manifest file so Lovable can edit confidently.
• Use Lovable Secrets UI for all sensitive environment variables and document the names in the manifest.
• Pin major versions and state fallback commands (e.g., NODE_VERSION, BUILD_CMD env var) to avoid “it works locally” surprises.
• When a terminal is required, note that in the manifest and trigger GitHub sync/export — do not ask users to run commands inside Lovable.

 

Lovable prompts to paste (use these in Chat Mode)

 

Paste each prompt into Lovable chat separately. They tell Lovable exactly what files to create or update.

• Create a framework manifest file:
  Prompt for Lovable: \`\`\` // Create a new file at .lovable/framework-preferences.md // Content should be plain markdown describing project preferences. // Include these headers and values (replace examples with actual project choices): // // Framework: Next.js // FrameworkVersion: 14.x // SSR: true // PackageManager: pnpm // NodeVersion: 20 // BuildCommand: pnpm build // DevCommand: pnpm dev -- -p 3000 // DevPort: 3000 // CSSFramework: TailwindCSS // Database: Supabase // Auth: Supabase Auth // EnvSecrets: SUPABASE_URL, SUPABASE_KEY // Notes: "If a terminal is required for local tasks, add a CI job in .github/workflows and mark here." // // Save exactly to .lovable/framework-preferences.md \`\`\`
• Patch package.json to be explicit:
  Prompt for Lovable: \`\`\` // Update package.json at root: add an "engines" field and explicit scripts. // If engines exists, merge values. Example additions: // // "engines": { // "node": ">=20 <21" // }, // "scripts": { // "dev": "pnpm dev -- -p 3000", // "build": "pnpm build", // "start": "pnpm start" // } // // Apply the change as a patch/diff to /package.json \`\`\`
• Document environment secrets and guide to set them:
  Prompt for Lovable: \`\`\` // Update .lovable/framework-preferences.md (append) to include a "How to set secrets in Lovable" section: // - List each secret name (SUPABASE_URL, SUPABASE_KEY) // - Explicitly instruct: "Open Lovable Secrets UI -> Create secret with name SUPABASE\_KEY -> paste value." // - Note that secrets are required for Preview and Publish and that values must be set before Publish. // Save edits to .lovable/framework-preferences.md \`\`\`
• Add a README snippet so reviewers know what to expect:
  Prompt for Lovable: \`\`\` // Update README.md: add a short "Framework Preferences" section near the top including the same fields as .lovable/framework-preferences.md // Example line: "This project uses Next.js 14 (SSR), Node >=20, pnpm. See .lovable/framework-preferences.md for full details." // Apply as an edit to /README.md \`\`\`
• When terminal-only steps are required:
  Prompt for Lovable: \`\`\` // If any step requires running a CLI (e.g., migrating DB, seeding), append a "Local / CI steps" section to .lovable/framework-preferences.md // Include exact commands and mark them as "outside Lovable (requires terminal):" so the repo consumer knows to run them locally or in CI. // Save edits to .lovable/framework-preferences.md \`\`\`

 

Why this works in Lovable

 

• Files and explicit scripts let Lovable edit and Preview reliably — no CLI required inside Lovable.
• Secrets UI is used for runtime-only values; manifest points to those names so the agent and reviewers won’t guess.
• GitHub sync/export is only recommended when a terminal/CI job must be added and run outside Lovable.