sucupira
d0d80a105e
- Rebuild complet SvelteKit 2 + Svelte 5 runes + TypeScript, adapter-static - Images self-hébergées optimisées au build (vite-imagetools), fonts Archivo/Inter en woff2 local — BunnyCDN et Google Fonts supprimés (corrige les 403 d'images) - Tokens charte OKI, thème sombre par défaut / clair opt-in, zéro emoji (set SVG) - Motion : KineticText (stagger syncopé gwoka), ScrollProgressBar, View Transitions - Village SVG isométrique pour les services hébergés + fallback accessible - PWA (manifest + SW hors-ligne), 404 en KA, CSP nettoyée (.htaccess + _headers) - Lighthouse mobile : 91/100/100/100 — JS initial 67 Ko gzip
46 lines
2.7 KiB
Markdown
46 lines
2.7 KiB
Markdown
# Déploiement — o-k-i.net (SvelteKit statique)
|
|
|
|
Le site est entièrement pré-rendu : `npm run build` produit un dossier `build/` de fichiers statiques servable par n'importe quel hébergement de fichiers, **sans serveur Node**.
|
|
|
|
```bash
|
|
npm install
|
|
npm run build # → build/
|
|
```
|
|
|
|
Contenu notable de `build/` : pages HTML par route (`index.html`, `dons/index.html`, `en/…`), assets fingerprintés (`_app/`), polices (`fonts/`), PDF presse (`assets/press/`), PWA (`sw.js`, `registerSW.js`, `manifest.webmanifest`), `404.html`, `robots.txt`, `sitemap.xml`.
|
|
|
|
---
|
|
|
|
## Option A — o2switch (Apache, mutualisé)
|
|
|
|
1. Builder en local puis transférer **le contenu de `build/`** à la racine web du domaine (via FTP/SFTP ou le gestionnaire de fichiers cPanel), typiquement `public_html/`.
|
|
2. **Conserver le fichier `build/.htaccess`** (fichier caché — vérifier qu'il est bien transféré). Il contient :
|
|
- redirection HTTP → HTTPS (compatible proxy),
|
|
- `ErrorDocument 404 /404.html`,
|
|
- headers de sécurité (HSTS, CSP `default-src 'self'`, `X-Frame-Options: DENY`, `nosniff`, `Referrer-Policy`, `Permissions-Policy`),
|
|
- cache immutable pour `/_app/` et `/fonts/`.
|
|
3. HTTPS : activer le certificat Let's Encrypt dans cPanel (la redirection exempte `.well-known/acme-challenge/`).
|
|
4. Vérifications post-déploiement :
|
|
- `curl -sI https://o-k-i.net/` → headers de sécurité présents,
|
|
- `curl -s https://o-k-i.net/ | grep -c "b-cdn.net\|googleapis"` → `0`,
|
|
- une URL inexistante → page 404 designée avec statut 404.
|
|
|
|
> Le service worker (`sw.js`) est servi en `text/javascript` par défaut sous Apache — rien à configurer.
|
|
|
|
## Option B — Cloudflare Pages
|
|
|
|
1. Projet Pages connecté au dépôt, ou déploiement direct : `npx wrangler pages deploy build`.
|
|
2. Configuration du projet :
|
|
- **Build command** : `npm run build`
|
|
- **Build output directory** : `build`
|
|
3. **Le fichier `build/_headers` est pris en compte automatiquement** par Cloudflare Pages (headers de sécurité + cache immutable). Ne pas le supprimer.
|
|
4. La page 404 : Cloudflare Pages sert automatiquement `/404.html` avec le statut 404 pour les routes inconnues.
|
|
5. HTTPS/HSTS : gérés par Cloudflare ; le header HSTS est aussi dans `_headers`.
|
|
|
|
## Points communs
|
|
|
|
- **Aucune variable d'environnement** n'est nécessaire au build.
|
|
- Le site fonctionne sans JavaScript côté serveur ; les seuls scripts sont statiques (`theme.js`, `lang-redirect.js`, `registerSW.js`, bundles `_app/`).
|
|
- CSP stricte : si vous ajoutez un jour une ressource externe, il faudra l'ajouter à la CSP (dans `.htaccess` ET `_headers`) — ou mieux, la self-héberger.
|
|
- Les PDF de presse (~34 Mo dans `assets/press/`) font partie du déploiement.
|