Template GitHub per nuovi progetti. Standardizza il tooling iniziale (linting, formattazione, TypeScript, issue/PR template) così da evitare di reimpostare tutto da zero ogni volta.
.
βββ .github/
β βββ ISSUE_TEMPLATE/
β β βββ bug.yaml # Segnalazione bug
β β βββ feat.yaml # Richiesta nuova funzionalitΓ
β β βββ docs.yaml # Richiesta aggiornamento documentazione
β β βββ refactor.yaml # Richiesta refactoring
β β βββ test.yaml # Richiesta test
β β βββ config.yml # Disabilita issue vuote
β βββ workflows/
β β βββ ci.yml # CI disattivato (if: false)
β β βββ opencode.yml # Workflow AI per PR e issue
β β βββ release-please.yml # Automazione versioni e rilascio
β βββ pull_request_template.md
βββ .gitignore
βββ .prettierrc
βββ .prettierignore
βββ eslint.config.js
βββ LICENSE
βββ package.json
βββ tsconfig.json
βββ tsconfig.app.json
βββ tsconfig.node.json
βββ README.md
Template YAML allineati ai Conventional Commits:
| File | Titolo | Label | Cosa richiede |
|---|---|---|---|
bug.yaml |
bug: |
bug |
Descrizione, riproduzione, log/stack trace |
feat.yaml |
feat: |
feature, enhancement |
Criteri di accettazione, task list |
docs.yaml |
docs: |
documentation |
Doc mancante o obsoleta |
refactor.yaml |
refactor: |
refactor |
Struttura, performance, modularitΓ |
test.yaml |
test: |
test |
Copertura, scenari, task |
config.yml disabilita la creazione di issue vuote β si usano solo i template.
Workflow GitHub Actions che esegue opencode (AI agent) su issue e PR quando un commento contiene /oc o /opencode. Per il setup vedi la sezione dedicata piΓΉ sotto.
Struttura standard: Descrizione, Riferimenti Issue, Modifiche Effettuate, Checklist.
Workflow CI disattivato di default (if: false). Esegue pnpm install --frozen-lockfile e pnpm format:check su ogni PR verso main. Per attivarlo, rimuovi la riga if: false dal job.
Placeholder generico. Sostituiscilo con un .gitignore adatto al tuo stack (es. Node, Python).
Regole base di Prettier + plugin prettier-plugin-tailwindcss:
- semi, single quote, trailing comma es5, print width 80, tab width 2
- Override per YAML (print width 120)
- Override per Markdown (print width 100, prose wrap preserve)
Esclude da Prettier: node_modules, dist, build, .netlify, .github, pnpm-lock.yaml, routeTree.gen.ts e altri.
Flat config con:
- Parser: TypeScript (
@typescript-eslint/parser) - Plugin: Prettier, TypeScript, React (opzionale β segnato con
// [React]) - Regole:
no-unused-vars(error),no-explicit-any(warn),prettier/prettier(warn)
- Package manager:
pnpm@9.14.2 - Scripts:
lint:check/lint:fixβ ESLintformat:check/format:fixβ Prettiertype-checkβtsc --noEmit
Nessuna dipendenza inclusa. Le installi tu in base al progetto.
Pattern standard Vite a 3 file:
| File | Target | Include |
|---|---|---|
tsconfig.json |
β | Root, collega i due riferimenti |
tsconfig.app.json |
ES2020 + DOM + jsx | src/ |
tsconfig.node.json |
ES2022 | vite.config.ts |
Licenza MIT.
Il template fornisce la base per:
| Strumento | Cosa fa |
|---|---|
| pnpm | Package manager veloce |
| TypeScript | Controllo statico dei tipi |
| ESLint | Analisi statica del codice |
| Prettier | Formattazione automatica |
| opencode | AI agent su GitHub Actions |
- Su GitHub, clicca "Use this template" sul repository.
- Seleziona owner e nome del nuovo repository.
- Clona il repository in locale e installa le dipendenze:
pnpm install
- Modifica
package.json:"name"β metti il nome del progetto"version":"0.0.0"β aggiorna se necessario
- Configura il repository su GitHub (protezione branch, ecc.) β vedi sezione dedicata.
Copia i file che ti servono:
git clone https://github.com/Smailen5/templates.git
xcopy /E /I templates\.github C:\tuo-progetto\.github
xcopy templates\.prettierrc C:\tuo-progetto\
xcopy templates\.prettierignore C:\tuo-progetto\
xcopy templates\eslint.config.js C:\tuo-progetto\
xcopy templates\package.json C:\tuo-progetto\
xcopy templates\tsconfig*.json C:\tuo-progetto\Oppure scarica singolarmente i file dalla pagina GitHub.
Non tutti i progetti usano lo stesso stack. Ecco cosa togliere in base alle tue esigenze.
In eslint.config.js rimuovi tutto ciΓ² che Γ¨ segnato con // [React]:
- Le import:
eslint-plugin-react,eslint-plugin-react-hooks,eslint-plugin-react-refresh - Nel blocco
plugins: le righereact,"react-hooks","react-refresh" - Nel blocco
rules:...react.configs.recommended.rules,...reactHooks.configs.recommended.rules - Le regole React:
react/react-in-jsx-scope,react/prop-types, ecc. - Il blocco
settings: { react: { version: "detect" } }
- Elimina
tsconfig.json,tsconfig.app.json,tsconfig.node.json - In
package.jsonrimuovi lo scripttype-check - In
eslint.config.jsrimuovi il parser TypeScript e il plugin@typescript-eslint - Aggiorna
.gitignore(rimuovi righe TypeScript-specifiche se presenti)
- In
.prettierrcrimuovi"prettier-plugin-tailwindcss"dalla listaplugins
- In
package.jsonrimuovi o modifica il campopackageManager - Usa
npm installoyarnal posto dipnpm install
Il file .github/workflows/opencode.yml integra opencode, un AI agent che risponde ai comandi su issue e PR.
Il workflow si attiva quando pubblichi un commento che contiene /oc o /opencode su una issue o PR. L'agente:
- Legge il contesto della issue/PR
- Esegue il task richiesto (modificare codice, scrivere doc, fare review, ecc.)
- Pubblica il risultato come commento nella issue/PR
Scrivi in un commento su una issue o PR:
/oc aggiungi una sezione FAQ al README
/opencode rivedi questa PR e fammi un riepilogo delle modifiche
Per funzionare, il workflow ha bisogno di un API key di DeepSeek (o del provider che preferisci) salvata come secret nel repository.
- Vai su DeepSeek Platform e genera un API key.
- Su GitHub, vai in Settings > Secrets and variables > Actions del tuo repository.
- Clicca "New repository secret" e crea:
- Name:
DEEPSEEK_API_KEY - Secret: incolla la chiave generata
- Name:
- Il workflow la userΓ automaticamente tramite
${{ secrets.DEEPSEEK_API_KEY }}.
Il workflow usa deepseek/deepseek-v4-flash che ha un costo molto basso. Con un uso normale (decine di task al mese) la spesa Γ¨ trascurabile (centesimi di dollaro).
Se vuoi cambiare modello o provider, modifica il file .github/workflows/opencode.yml:
- name: Run opencode
uses: anomalyco/opencode/github@latest
env:
YOUR_API_KEY: ${{ secrets.YOUR_API_KEY }}
with:
model: provider/modello-desiderato
prompt: |
Quando fai commit, usa i Conventional Commits senza scope.
Prefissi: feat, fix, docs, chore, refactor, test.
Scrivi i messaggi in italiano.Cambia DEEPSEEK_API_KEY con la variabile del tuo provider, model con l'ID del modello e prompt con le istruzioni che preferisci per l'agente.
Il file .github/workflows/release-please.yml automatizza la gestione delle versioni del progetto.
A ogni push sul branch main, release-please analizza i commit usando i Conventional Commits per determinare il tipo di incremento di versione (patch, minor, major):
feat:β minorfix:β patchperf:β patch- Breaking changes β major
Poi apre o aggiorna una Release PR che:
- Propone il nuovo numero di versione
- Aggiorna
package.jsoncon la versione - Genera il
CHANGELOG.mdbasato su tutti i commit - Crea una GitHub Release quando la PR viene mergiata
- Scrivi i commit usando i Conventional Commits (es.
feat:,fix:,docs:). - Quando vuoi rilasciare, vai su GitHub e apri la Release PR creata da release-please.
- Verifica il changelog e la versione proposta.
- Se tutto ok, mergia la PR. release-please creerΓ automaticamente il tag e la GitHub Release.
Per configurazioni personalizzate (es. sezioni changelog, plugin), crea un file release-please-config.json e aggiorna il workflow secondo la documentazione ufficiale.
Le impostazioni di GitHub non vengono ereditate dal template. Su ogni nuovo repository vanno configurate manualmente.
Settings > Actions > General > Workflow permissions:
- β "Read and write permissions"
- β "Allow GitHub Actions to create and approve pull requests"
Senza questa impostazione, workflow come release-please non possono creare PR.
Settings > General > Pull Requests:
- β "Always suggest updating pull request branches"
- β "Automatically delete head branches"
- "Pull request permissions": Only collaborators
Settings > General > Merge button:
- β "Allow merge commits" β disabilita
- β "Allow rebase merging" β disabilita
- "Default commit message": Pull request title
Usa la classica branch protection rule (non Rulesets):
- Settings > Branches > Branch protection rules β "Add branch protection rule"
- Branch name pattern:
main - Spunta:
- β "Require a pull request before merging"
- β "Require branches to be up to date before merging"
- β "Require status checks to pass before merging" (se hai CI)
- Nella sezione "Rules applied to everyone including administrators":
- β "Do not allow bypassing the above settings"
- β "Require linear history"
- "Lock branch" β lascialo spento (blocca main completamente)
- Salva.
Con questa configurazione:
- Nessuno pusha direttamente su
main - Ogni modifica passa da una PR
- Serve almeno una review approvata per fare merge
Distribuito con licenza MIT. Vedi LICENSE per i dettagli.