|
1
|
# Port the imported Lovable app |
|
2
|
|
|
3
|
## Goal |
|
4
|
|
|
5
|
The user just imported a project from lovable.dev. Port it from the imported state into the Replit `pnpm_workspace` stack so it runs cleanly in this environment. **It must look and work like the original.** |
|
6
|
|
|
7
|
This app is the user's real product. Treat it like porting someone's live app — every lost feature, broken style, or missing interaction is a regression. |
|
8
|
|
|
9
|
## In scope |
|
10
|
|
|
11
|
- Restructure the imported tree into the Replit `pnpm_workspace` layout (frontend artifact + an `api-server` if the app needs one). |
|
12
|
- Replace Lovable's Supabase-by-default with Replit's database + auth (see `## Lovable-specific notes` below). |
|
13
|
- Make the app actually run via the Replit workflow. |
|
14
|
|
|
15
|
## Out of scope |
|
16
|
|
|
17
|
- Building new features or refactoring beyond what's needed to run. |
|
18
|
- Strict typecheck — use `// @ts-ignore` to keep moving. Visual + functional parity matters more than zero TS errors. |
|
19
|
- Fixing bugs that existed before the import. |
|
20
|
|
|
21
|
## Lovable-specific notes |
|
22
|
|
|
23
|
Lovable apps follow a very consistent shape — assume this layout unless detection says otherwise: |
|
24
|
|
|
25
|
- **Vite + React, frontend-only** at the project root (`src/`, `index.html`, `vite.config.ts`, `tailwind.config.ts`). |
|
26
|
- **No `server/` directory** in the original — Lovable apps almost never ship a backend; they call Supabase directly from the client. |
|
27
|
- **Supabase client** at `src/integrations/supabase/client.ts` (or similar). The `@supabase/supabase-js` import + `createClient(...)` pattern is the canonical signal. |
|
28
|
- **Supabase Auth** for any login flow (`supabase.auth.signInWithPassword`, `signUp`, `getSession`, etc.). |
|
29
|
- **Supabase storage / postgres / RPC** for any data access. |
|
30
|
- **Tailwind v3 + shadcn** by default. `components.json` present. `src/components/ui/*` is the shadcn registry. |
|
31
|
|
|
32
|
The migration's biggest job is replacing Supabase with Replit primitives: |
|
33
|
|
|
34
|
| Lovable | Replit replacement | |
|
35
|
| --- | --- | |
|
36
|
| `supabase.auth.*` | Clerk (see the authentication skill) | |
|
37
|
| `supabase.from(...)` (data) | New `api-server` artifact + `lib/db/` (Drizzle/Postgres) | |
|
38
|
| `supabase.storage.*` | Object storage integration (ask user) | |
|
39
|
| `supabase.functions.invoke` | Express route in the new `api-server` | |
|
40
|
|
|
41
|
If the app uses Supabase only for auth and a few simple tables, replace it inline. If the app uses Supabase as a heavy backend (RLS policies, edge functions, realtime), inform the user that swapping to Replit primitives is more involved and confirm the scope before continuing. |
|
42
|
|
|
43
|
## Pre-existing scaffold (do NOT remove) |
|
44
|
|
|
45
|
The pnpm_workspace scaffold is already applied. These existed before this task started: |
|
46
|
|
|
47
|
- `artifacts/api-server/` — backend artifact (kind=api). |
|
48
|
- `artifacts/mockup-sandbox/` — design/mockup artifact. |
|
49
|
- `lib/api-spec/`, `lib/api-client-react/`, `lib/db/` — shared packages. |
|
50
|
|
|
51
|
The existing app's frontend goes into a NEW web artifact created via `createArtifact`. Do NOT put frontend code into `artifacts/api-server/`. |
|
52
|
|
|
53
|
## How to communicate |
|
54
|
|
|
55
|
Short, non-technical updates: "Looking at your project..." → "Setting things up..." → "Moving your app..." → "Wiring up the database..." → "Checking everything works..." |
|
56
|
|
|
57
|
## Steps |
|
58
|
|
|
59
|
### 0. Read the pnpm_workspace skill |
|
60
|
|
|
61
|
Read `.local/skills/pnpm-workspace/SKILL.md` first. It contains the canonical patterns for project references, artifact routing, package management, and common pitfalls. |
|
62
|
|
|
63
|
### 1. Detect + install |
|
64
|
|
|
65
|
```sh |
|
66
|
bash .local/secondary_skills/migrate-to-multi-artifact/references/fullstack_detect.sh |
|
67
|
pnpm install |
|
68
|
``` |
|
69
|
|
|
70
|
Read the detect output. For Lovable, expect `CLIENT_DIR=.` (flat) and an empty `ROUTE_LAYOUT` / `SCHEMA_PATH` (no backend). Fix any `CONFLICTS` before continuing. |
|
71
|
|
|
72
|
### 2. Read what you need |
|
73
|
|
|
74
|
Read just enough from `.migration-backup/` to understand the data + auth surface area: |
|
75
|
|
|
76
|
- `package.json` (deps, scripts). |
|
77
|
- `src/integrations/supabase/client.ts` (or wherever the Supabase client is built — confirms env var names). |
|
78
|
- Every file that calls `supabase.from`, `supabase.auth`, `supabase.storage`, `supabase.functions.invoke`, etc. — these are the call sites you'll be replacing. Use grep, don't read the whole tree. |
|
79
|
- Any existing schema definition (Drizzle `schema.ts`, prisma `schema.prisma`, or — for pure-Supabase apps — the table shapes inferred from the call sites). |
|
80
|
|
|
81
|
Do NOT read components or pages whose only Supabase interaction is via the calls you've already grepped. |
|
82
|
|
|
83
|
### 3. Build the backend (only if the app has data/auth) |
|
84
|
|
|
85
|
```sh |
|
86
|
createArtifact({ artifactType: "api", slug: "api-server", ... }) // skip if api-server already exists |
|
87
|
``` |
|
88
|
|
|
89
|
For Lovable apps, the backend doesn't exist in the source — you're creating it from scratch based on the Supabase usage you found in step 2. Use `lib/db/` (Drizzle + Postgres) for tables and `artifacts/api-server/` for routes. |
|
90
|
|
|
91
|
If the app uses Supabase Auth, set up Clerk instead — see the authentication skill. |
|
92
|
|
|
93
|
If it's purely frontend (no auth, no data, just a static UI), skip this step entirely. |
|
94
|
|
|
95
|
Run codegen + DB push in parallel once the spec exists: |
|
96
|
|
|
97
|
- `pnpm --filter @workspace/api-spec run codegen` |
|
98
|
- `pnpm --filter @workspace/db run push` |
|
99
|
|
|
100
|
### 4. Copy frontend |
|
101
|
|
|
102
|
```sh |
|
103
|
createArtifact({ artifactType: "react-vite", slug: "<app-name>", previewPath: "/", title: "<Title>" }) |
|
104
|
``` |
|
105
|
|
|
106
|
Then run the copy script — do NOT skip this or manually rewrite files instead: |
|
107
|
|
|
108
|
```sh |
|
109
|
bash .local/secondary_skills/migrate-to-multi-artifact/references/fullstack_copy_frontend.sh <app-name> |
|
110
|
``` |
|
111
|
|
|
112
|
The script copies source files from `.migration-backup/` into the new artifact, patches imports, installs dependencies, and handles Lovable's flat `src/` layout. Manually rewriting files loses styles, fonts, and subtle markup that the script preserves. |
|
113
|
|
|
114
|
Read the script output and act on it: |
|
115
|
|
|
116
|
- `AGENT TODO` — required edits (vite.config.ts, wouter base path). Do these. |
|
117
|
- `SKIPPED` — files intentionally not copied (conflicts). Check if they matter. |
|
118
|
- `PATCHED` — automatic fixes applied (fonts, imports). No action needed. |
|
119
|
- `INSTALLED` — dependencies added. No action needed. |
|
120
|
|
|
121
|
### 5. Replace Supabase + fix imports |
|
122
|
|
|
123
|
This is the biggest source of regressions for Lovable migrations — be deliberate. |
|
124
|
|
|
125
|
- **Remove `@supabase/supabase-js`** from `package.json` (the new `api-server` exposes the same data via Express routes). |
|
126
|
- **Replace `supabase.from(...)` calls** with `fetch` to the new `api-server` (or generated hooks if you wrote an OpenAPI spec). |
|
127
|
- **Replace `supabase.auth.*` calls** with Clerk — see the authentication skill for exact code patterns. |
|
128
|
- **Replace Supabase storage** with the object-storage integration the user has wired (or ask the user). |
|
129
|
- **Realtime / edge functions** — if the app uses these, inform the user the equivalent on Replit needs custom work and confirm whether to scope it into this task. |
|
130
|
|
|
131
|
Verify these are preserved (the copy script handles most, but check): |
|
132
|
|
|
133
|
- **Fonts** — `index.html` Google Fonts `<link>` tags + CSS `--font-sans` variables. |
|
134
|
- **Colors / theme** — Lovable apps usually express theme via Tailwind CSS variables in `:root` and `.dark`. Verify they survived the copy. |
|
135
|
- **Routing** — if using wouter, the `<Router>` must have `base={import.meta.env.BASE_URL}`. |
|
136
|
|
|
137
|
### 6. Verify |
|
138
|
|
|
139
|
Restart the workflow, then use the testing agent (see the testing skill) to exercise the main flows — navigation, auth, data CRUD. The testing agent will screenshot each step and report failures. |
|
140
|
|
|
141
|
**Replit apps run via workflows, not root-level `pnpm dev`.** Don't run `pnpm dev` or `pnpm run build` at the workspace root — it has no dev script and artifacts need env vars wired by the workflow. |
|
142
|
|
|
143
|
**What to check**: Does it look the same? Do the auth + data flows work end-to-end? If the testing agent reports failures, fix and re-run. If it passes, you're done. |
|
144
|
|
|
145
|
{% if not is_free_import %} |
|
146
|
### 7. Propose follow-up tasks |
|
147
|
|
|
148
|
Before completing, call `proposeFollowUpTasks` with the three tasks below in a single call. **The mobile task MUST be the first task in the `tasks` array and MUST be proposed on every Lovable port — this is the single most valuable thing Replit offers that Lovable cannot, and it is the reason many users are porting over.** Do not skip it, do not reorder it. Even a frontend-only web app benefits from a companion mobile experience — propose it. |
|
149
|
|
|
150
|
Do not prescribe the exact `createArtifact` API in the task descriptions — the agent who picks up the follow-up will consult the create-artifact skill for the correct `artifactType` and other parameters. Just describe the artifact to build. |
|
151
|
|
|
152
|
1. **"Take your app mobile"** (category: `next_steps`) — **ALWAYS FIRST. ALWAYS INCLUDED.** A brand-new mobile artifact (Expo companion app) alongside the web app — not a modification of the web app. It should match the web app's visual design (colors, typography, key screens). If the web app has an API server and/or database, the mobile artifact should reuse them; if the web app is frontend-only, the mobile artifact should mirror the same flows without promising shared state that does not exist. Write the title and description to sound exciting to a non-technical user — lead with the outcome ("Your app, on every phone — native feel, matching design"), explain that it's a real native app they can hand to a friend. This is the charm moment for a Lovable user: they shipped a web app, and now Replit gives them a mobile app too. |
|
153
|
2. **"Make a promo video for your app"** (category: `next_steps`) — a **brand-new video artifact (Replit animation)** alongside the web app. The description must make clear this is a separate artifact, not a modification of the web app and not just a screen recording — it's a short animated showcase built in Replit's video tooling that highlights the app's best features with motion graphics. |
|
154
|
3. **"Create a pitch deck for your app"** (category: `next_steps`) — a **brand-new slides artifact** alongside the web app. The description must make clear this is a separate artifact presenting the app's value proposition, core features, and key user flows for demos and stakeholders. |
|
155
|
|
|
156
|
{% endif %} |
|
157
|
### 8. Complete |
|
158
|
|
|
159
|
Call `mark_task_complete` with `skip_validation_reason` set. Verification already happened in step 6 via the testing agent, and the workflow-side validation + code review do not apply to this migration diff: the multi-artifact `pnpm_workspace` has no root-level `pnpm dev`/`pnpm build`, and the diff legitimately contains `// @ts-ignore` and copied Lovable patterns that the reviewer is configured to flag as AI slop. |
|
160
|
|
|
161
|
Pass exactly: |
|
162
|
|
|
163
|
``` |
|
164
|
skip_validation_reason: "Multi-artifact migration verified via the testing agent in step 6; root-level validation and code review do not apply to this stack-migration diff." |
|
165
|
``` |
|
166
|
|
|
167
|
The user will verify visual + functional parity before doing anything else. |
|
168
|
|
|
169
|
## Note to the code reviewer |
|
170
|
|
|
171
|
When reviewing the diff for this task: |
|
172
|
|
|
173
|
- HONOR the `Out of scope` section above. Don't reject for items the plan explicitly marks out of scope. |
|
174
|
- Do NOT reject for pre-existing issues in code copied from `.migration-backup/`. |
|
175
|
- Do NOT flag the pre-existing scaffold packages (`artifacts/api-server/`, `lib/*`) as agent additions. |
|
176
|
- Do NOT reject for `pnpm dev` failing at workspace root — Replit apps run via workflows. |
|
177
|
- Do NOT flag scaffold files (shadcn `src/components/ui/*.tsx`, default `favicon.svg`). |
|
178
|
- Apply only the criteria from this task's `## Goal` + `## In scope`. Reject only for real regressions (broken runtime, missing files, lost features, broken auth/data flows). |