For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /it/docs/web/project-structure.md (or send Accept: text/markdown).
Struttura del progetto
Trova le app, i pacchetti condivisi e le frontiere tra loro.
Installazione e configurazione
Prima di qualsiasi passaggio, leggere Prima di iniziare e Nozioni di base sui terminali. Queste istruzioni presuppongono che tu abbia aperto l'intero supastack monorepo in VS Code; la sua radice package.json contrassegna la radice del repository. Nei comandi pnpm, un pacchetto dell'area di lavoro è un'app o una cartella di codice condiviso; nel prodotto, uno spazio di lavoro è il contenitore dei dati di un team e il limite di sicurezza. corepack pnpm --filter ... seleziona un pacchetto dal monorepo mentre i comandi vengono eseguiti dalla sua radice. Se hai aperto solo una cartella mobile o desktop sincronizzata, non contiene il backend Web, la configurazione di Docker o gli script root: esegui il backend da questo monorepo o da un server ospitato raggiungibile e utilizza gli script della cartella della piattaforma. Una variabile di ambiente è un'impostazione denominata memorizzata in un file .env locale o nel dashboard dell'hosting; riavvia l'app pertinente dopo averla modificata e mantieni i segreti del server fuori dai valori NEXT_PUBLIC_ e EXPO_PUBLIC_.
1. Aprire il pacchetto root.json in VS Code, quindi cercare apps/web per il sito Web, apps/mobile per Expo, apps/desktop per la shell desktop e i pacchetti per le parti condivise.
2. Dalla root del repository eseguire corepack pnpm --filter @supastack/web dev.
3. Apertura http://localhost:3000. Previsto: l'app Web viene avviata da apps/web mentre i pacchetti condivisi rimangono nello stesso repository; la finestra Desktop racchiude questa app Web anziché contenere un secondo prodotto.
Il workspace pnpm contiene Next.js in apps/web, Expo in apps/mobile e i pacchetti condivisi sotto packages. Esegui i comandi del workspace dalla radice del repo. Le route dell'applicazione compongono i moduli condivisi; il comportamento specifico del prodotto appartiene al prodotto consumatore.
Leggi AGENTS.md e .ai/PROJECT_CONTEXT.md prima di cambiare comportamento. I mirror dei file in .ai/ spiegano decisioni e vincoli non sempre evidenti da un componente da solo.
apps/web/app/ Routes and layouts
apps/web/src/ Web components and server composition
apps/mobile/ Expo application
packages/ Shared contracts and adapters
tests/ Cross-module and browser checks
docs/ Operational guidesComandi da copiare
Segui i commenti per vedere in quale cartella viene eseguito un comando. Se due terminali sono etichettati, apri due finestre di terminale e mantieni il primo comando in esecuzione mentre usi il secondo.
corepack pnpm --filter @supastack/web devDove va una modifica
Prima di modificare, decidi quale app o pacchetto possiede la modifica. La regola pratica: se solo una superficie del prodotto ne ha bisogno, mettila in quell'app; se ne hanno bisogno tutte, mettila in un pacchetto condiviso sotto packages/.
Il repository Web e il monorepo All Platforms contengono tutte le cartelle qui sotto. Un checkout Mobile o Desktop standalone contiene solo la propria app — il codice del server resta nel repository Web.
- Una nuova pagina marketing o landing →
apps/web/app/— il sito pubblico. - Una nuova schermata dentro il prodotto dopo l'accesso →
apps/web/app/per la route piùapps/web/src/per la sua logica — le pagine compongono i pacchetti condivisi. - Una nuova route API →
apps/web/app/api/— la metà server dell'app Web. - Una modifica condivisa da ogni app — una tabella del database, un contratto, un adapter di provider → la cartella corrispondente in
packages/. - Una schermata solo per telefono →
apps/mobile/— comunica con l'API dell'app Web invece di avere un proprio backend. - Un comportamento solo desktop →
apps/desktop/— la shell Tauri avvolge l'app Web e quasi mai duplica la UI del prodotto.
Flusso di implementazione
Inizia dalla route che possiede l'azione utente, segui il suo handler server, poi ispeziona il pacchetto condiviso che chiama. Un componente UI non deve ricreare la risoluzione del workspace, l'autorizzazione di fatturazione o la scelta del provider.
Quando aggiungi una route, decidi se è pubblica o autenticata. Risolvi il possesso autenticato lato server prima di accedere ai record utente e tieni le credenziali server fuori dagli import client.
Verifica e risoluzione dei problemi
Se il comando segnala che nessun progetto corrisponde al filtro, controlla che il terminale sia nella cartella contenente il root package.json. Se la porta 3000 è già in uso, arrestare prima l'altro server Web locale. Non cercare una chat desktop separata o un'implementazione di accesso; la shell del desktop carica il backend Web.
Esegui i test pertinenti e il typecheck dopo aver cambiato un contratto di pacchetto. Ispeziona i consumatori web e mobile quando cambi tipi condivisi. Un build web riuscito da solo non stabilisce la compatibilità con l'app nativa.