142 lines
8.7 KiB
Markdown
142 lines
8.7 KiB
Markdown
<!-- file: docs/rules/710-TAURI.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# Profil Tauri 2
|
|
|
|
## Rôle et applicabilité
|
|
|
|
Ce document possède les règles réutilisables propres à une application utilisant Tauri 2 comme host natif et orchestrateur d'intégration entre un backend Rust et un frontend WebView.
|
|
|
|
Il complète [`700-FRAMEWORKS.md`](700-FRAMEWORKS.md) et [`510-RUST_CARGO.md`](510-RUST_CARGO.md). Les profils plateforme réellement ciblés, par exemple [`610-ANDROID.md`](610-ANDROID.md), restent applicables et possèdent leurs contraintes de SDK, packaging et smoke de plateforme.
|
|
|
|
Le profil est volontairement borné à Tauri 2. Une future génération incompatible du framework doit être réévaluée avant d'hériter automatiquement de ces règles.
|
|
|
|
## Composition avec le frontend
|
|
|
|
Tauri ne détermine pas à lui seul le framework frontend, le bundler ou le package manager du projet.
|
|
|
|
PGR MUST NOT imposer Vite, TypeScript, npm, pnpm, yarn, Bun, WASM ou une arborescence frontend particulière uniquement parce que Tauri est utilisé.
|
|
|
|
Le frontend peut être possédé par son propre profil ou par les règles locales du projet. Le profil Tauri possède seulement le contrat d'intégration entre ce frontend et le host natif.
|
|
|
|
## Layout et fichiers possédés par Tauri
|
|
|
|
PGR MUST NOT imposer universellement un répertoire `src-tauri/` ni recopier le layout d'un corpus source. Le projet peut utiliser le layout standard de Tauri ou une intégration colocalisée différente lorsque la toolchain la supporte clairement.
|
|
|
|
Les éléments suivants appartiennent néanmoins au scope Tauri lorsqu'ils existent :
|
|
|
|
- le manifeste Cargo du host natif ;
|
|
- l'intégration build-time Tauri, généralement via `tauri-build` ;
|
|
- la configuration Tauri supportée par la version du framework, par exemple `tauri.conf.json` ;
|
|
- les capability files et permissions Tauri ;
|
|
- les icônes, ressources ou métadonnées de bundle référencées par la configuration ;
|
|
- les projets ou fichiers de plateforme produits/consommés par la toolchain Tauri.
|
|
|
|
Leur emplacement exact reste une décision du projet tant qu'il est supporté par la toolchain retenue.
|
|
|
|
## Ownership du build et hooks frontend
|
|
|
|
Lorsqu'une validation concerne l'intégration Tauri complète, le CLI Tauri est l'owner de l'orchestration.
|
|
|
|
Si `beforeDevCommand`, `beforeBuildCommand` ou un hook Tauri équivalent est configuré, la gate d'intégration SHOULD invoquer le CLI Tauri afin que ce hook soit exécuté dans le contexte prévu.
|
|
|
|
Ainsi :
|
|
|
|
```text
|
|
cargo check / cargo clippy
|
|
→ preuve Rust ciblée
|
|
|
|
frontend build/test direct
|
|
→ preuve frontend ciblée
|
|
|
|
Tauri CLI dev/build
|
|
→ preuve d'orchestration Tauri + hooks correspondants
|
|
```
|
|
|
|
Un projet MUST NOT considérer `npm run build`, `cargo build` ou une autre sous-commande isolée comme équivalente à un build Tauri lorsque la propriété à valider dépend des hooks, de `frontendDist`, des capabilities, du contexte Tauri ou du bundling.
|
|
|
|
Le CLI MAY être invoqué via `cargo tauri`, un script du package manager frontend ou une autre forme officiellement supportée. PGR n'impose pas le package manager qui sert de lanceur.
|
|
|
|
## `devUrl`, `frontendDist` et sorties frontend
|
|
|
|
`devUrl` et `frontendDist` doivent pointer vers les entrées/sorties réellement possédées par la chaîne frontend du projet.
|
|
|
|
PGR ne fixe ni port, ni nom de répertoire de distribution, ni profondeur relative universelle.
|
|
|
|
Le répertoire produit par le frontend est un artefact de build lorsqu'il est reproductible ; il SHOULD rester hors du source control sauf besoin explicite contraire. La configuration Tauri qui le référence reste, elle, source durable.
|
|
|
|
## Version produit
|
|
|
|
Lorsque l'application Tauri appartient au même release train que le projet, `VERSION` reste la version canonique de cette unité de release.
|
|
|
|
Pour Tauri 2, une configuration qui omet la propriété applicative `version` peut utiliser la version du package Cargo du host. Lorsqu'un workspace PGR hérite déjà `workspace.package.version`, cette chaîne SHOULD être préférée si elle évite une duplication sans perdre d'information :
|
|
|
|
```text
|
|
VERSION
|
|
↓
|
|
workspace.package.version
|
|
↓
|
|
package Cargo du host
|
|
↓
|
|
version applicative Tauri
|
|
```
|
|
|
|
Si une version Tauri explicite est conservée dans la configuration, elle MUST représenter la même release ou documenter clairement pourquoi elle constitue une unité indépendante.
|
|
|
|
Les numéros de version propres aux plateformes, par exemple Android `versionCode`, restent possédés par le profil plateforme concerné et ne sont pas assimilés au SemVer produit.
|
|
|
|
## Capabilities, permissions et frontière WebView/native
|
|
|
|
Les capability files et permissions Tauri sont du source de sécurité et SHOULD être versionnés lorsqu'ils définissent intentionnellement la surface exposée au frontend.
|
|
|
|
Le projet SHOULD accorder uniquement les permissions nécessaires aux fenêtres/webviews concernées. Ajouter un plugin ou une commande native ne justifie pas automatiquement une capability globale plus large.
|
|
|
|
Les schémas générés référencés par les capability files servent à l'outillage et à la validation de configuration ; ils ne deviennent pas pour autant la source normative de la politique de permissions.
|
|
|
|
Toute permission distante, origine distante ou extension de scope sensible doit être explicitement justifiée et validée comme frontière de sécurité.
|
|
|
|
## Plugins, CSP, fenêtres et bundles
|
|
|
|
PGR ne définit aucun catalogue de plugins Tauri obligatoires.
|
|
|
|
Plugins, CSP, nombre de fenêtres, labels, tailles, ports, `bundle.active`, targets de bundle, icônes et ressources restent des décisions du produit ou de la plateforme tant qu'aucun invariant plus général ne les impose.
|
|
|
|
Une règle locale MAY renforcer ces choix. Elle ne doit pas être remontée dans le profil Tauri uniquement parce qu'elle apparaît dans plusieurs applications d'un même projet.
|
|
|
|
## Artefacts générés et projets mobiles
|
|
|
|
Les dépendances frontend téléchargées et sorties de build reproductibles, telles que `node_modules/` ou le `frontendDist`, SHOULD rester hors Git.
|
|
|
|
PGR MUST NOT appliquer en revanche une exclusion universelle de tout répertoire `gen/`. Tauri peut générer des projets de plateforme qui deviennent ensuite le lieu de personnalisations Android/iOS intentionnelles. Le projet doit classifier chaque sous-arbre : reproductible/transitoire, configuration durable ou généré modifié volontairement.
|
|
|
|
Les secrets de signature, keystores, credentials et fichiers locaux restent hors Git conformément aux règles générales et aux profils plateforme applicables.
|
|
|
|
## Validation proportionnée
|
|
|
|
| Scope modifié | Preuve Tauri normalement pertinente | Ce que cette preuve ne remplace pas |
|
|
|-------------------------------------------------|------------------------------------------------------------------------|------------------------------------------------------|
|
|
| backend Rust uniquement | gates Rust/Cargo sélectionnées | frontend, hooks, WebView ou packaging |
|
|
| frontend uniquement | build/tests/smoke du frontend selon son owner | host natif ou packaging Tauri |
|
|
| hooks, config, capabilities, IPC ou intégration | `tauri dev` ou équivalent + smoke ciblé | package release de plateforme |
|
|
| bundling, ressources ou version packagée | `tauri build` ou équivalent + inspection/smoke de l'artefact | exigences d'un store ou d'une plateforme non exercée |
|
|
| Android/iOS | commande mobile Tauri applicable + gates du profil plateforme concerné | autres plateformes |
|
|
|
|
La syntaxe exacte de la commande dépend du lanceur choisi (`cargo`, npm, pnpm, etc.) et de la plateforme. Le delta/plan du projet doit fournir la commande concrète.
|
|
|
|
Un `cargo check` direct MAY rester utile pour une modification Rust ciblée, mais il ne constitue pas un smoke Tauri complet. Inversement, un full `tauri build` n'est pas requis lorsqu'aucune propriété d'intégration ou de packaging n'a été invalidée.
|
|
|
|
## Ce que le profil n'impose pas
|
|
|
|
Ce profil ne crée pas :
|
|
|
|
- de `tauri.conf.json` universel ;
|
|
- de port de développement par défaut PGR ;
|
|
- de frontend Vite/WASM obligatoire ;
|
|
- de plugin obligatoire ;
|
|
- de nombre ou taille de fenêtres ;
|
|
- de politique de bundle unique ;
|
|
- de layout `src-tauri/` obligatoire ;
|
|
- de version exacte de Tauri, `tauri-build` ou du CLI.
|
|
|
|
Ces décisions appartiennent au projet, à un profil plus spécifique ou à une future skeleton specification seulement lorsqu'une valeur réutilisable est réellement démontrée.
|