Démarrer

Prérequis

Node.js 22 (celui de la CI ; 20 au minimum).
Un navigateur récent pour le développement (Chrome, Firefox).
Pour les tests de bout en bout : Chromium pour Playwright (npx playwright install chromium) et un accès au réseau (cdn.basthon.fr).

Installation et commandes

bash

npm ci

npm ci installe aussi le hook Git pre-commit (Husky), qui refuse un commit tant qu'ESLint signale une erreur ou un avertissement.

Commande	Rôle
`npm run dev`	Serveur de développement de l'application seule (`http://localhost:5173/p/capycode/`)
`npm run lint`	ESLint, frontières entre couches comprises ; aucun avertissement toléré
`npm test`	Tests unitaires et de composants (Vitest)
`npm run test:e2e`	Tests de bout en bout (Playwright, vrais noyaux Basthon ; réseau nécessaire)
`npm run build`	Vérification des types (`vue-tsc`) puis build de production dans `dist/`
`npm run preview`	Sert le build de production
`npm run docs:dev`	Cette documentation, sur son propre serveur, avec rechargement à chaud
`npm run docs:build`	Build de la documentation dans `dist/doc/` (à lancer après `npm run build`)
`npm run docs:captures`	Refait les captures d'écran du guide d'utilisation, en français et en anglais (Playwright, vrais noyaux ; réseau nécessaire)

L'application est servie sous le chemin /p/capycode/ (option base de vite.config.ts), comme en production, et cette documentation sous /p/capycode/doc/. Pour un autre hébergement, la variable BASE_PATH change les deux : BASE_PATH=/ npm run build.

La documentation en développement

npm run dev ne sert pas la documentation : à l'adresse /p/capycode/doc/, il renvoie l'application. Lancez npm run docs:dev dans un second terminal ; si l'application occupe déjà le port 5173, VitePress prend le suivant (http://localhost:5174/p/capycode/doc/), et le terminal affiche l'adresse exacte. Pour voir les deux réunies comme en production : npm run build && npm run docs:build && npm run preview, puis http://localhost:4173/p/capycode/doc/.

Premier contact

Lancez npm run dev, ouvrez l'application, puis suivez la visite guidée du code : elle part de ce que vous voyez à l'écran pour arriver aux fichiers qui le produisent.

Organisation du dépôt

text

src/
├── i18n/                traduction : t(), langues, messages/ (en de référence, 10 langues)
├── utils/               fonctions pures partagées : chemins, dates, diff, noms, préférences, erreurs…
├── services/            logique sans Vue ni store
│   ├── vfs.ts           système de fichiers du workspace (LightningFS) et ses notifications
│   ├── git/             dépôt Git : lecture, inspection (diffs, contenus), opérations
│   ├── workspace.ts     le projet : système de fichiers + dépôt Git
│   ├── project/         projet de départ, instantanés et liens de partage, archive ZIP
│   ├── kernels.ts       noyaux Basthon (chargement)
│   ├── runtime.ts       sessions d'exécution sur les noyaux
│   ├── embedding.ts     options réglées par la page hôte (postMessage)
│   ├── extensions/      catalogue et types des extensions intégrées
│   ├── terminal/        interpréteur du terminal : une commande par module (fs/, git/, python/, system)
│   └── ruff.ts, linter.ts, outline.ts, search.ts, gitGraph.ts…
├── languages/           registre des langages : coloration, exécution, analyse, formatage, plan
├── stores/              état réactif (Pinia) ; editor/ est composé de modules ; extensions, diagnostics…
├── composables/         logique Vue réutilisable : projet, actions Git, clavier, poignées…
├── commands/            commandes de l'IDE : catalogue, menus, raccourcis
├── components/          composants Vue, par zone de l'écran (layout, sidebar, editor, console, common)
├── App.vue              assemblage de l'interface
├── main.ts              démarrage (polyfill Buffer, page hôte, langue, Vue, Pinia, service worker)
└── sw.ts                service worker (PWA)
tests/                   tests rangés par domaine (workspace, git, terminal, execution…) ; e2e/ : Playwright
docs/                    cette documentation (VitePress) ; docs/historique/ : notes du prototype, hors du site
public/                  fichiers publiés tels quels : icônes, .htaccess
vite-plugin-basthon.ts   publication des noyaux Basthon (voir « Intégration de Basthon »)
.claude/                 configurations pour Claude Code (serveurs de dev, preview, docs dans launch.json)
.agents/skills/          consignes des agents IA (.claude/skills en est un lien)
AGENTS.md                règles qui s'imposent à tout contributeur, humain ou agent

Un module trop long se découpe en dossier, par responsabilité : le dossier porte le nom de l'ancien module et son index.ts en garde l'API (@/stores/editor, @/services/git).

Tests

Voir la page Tests : rangement par domaine, faux noyau Basthon, tests de bout en bout.

Quelques pièges du développement

Serveur de dev et nouveaux fichiers chargés à la demande. Un dictionnaire de langue ajouté pendant que npm run dev tourne n'est pas vu : relancer le serveur (après un git pull qui en apporte un, par exemple). Il en va de même quand un module devient un dossier (editor.ts → editor/).
Service worker en local. npm run preview installe le service worker de l'application sur localhost:4173 ; il survit à l'arrêt du serveur. Pour repartir de zéro : outils de développement → Application → Unregister, ou un autre port.
Workspace du navigateur. Le projet vit dans l'IndexedDB capycode-fs du navigateur. Menu Fichier → Nouveau projet le vide ; pour retrouver le projet de départ, effacer les données du site (outils de développement → Application → Clear site data).

Démarrer ​

Prérequis ​

Installation et commandes ​

Organisation du dépôt ​

Tests ​