Skip to content

ARCHITECTURE-SUMMARY.md

Latest commit

 

History

History
314 lines (222 loc) · 9.47 KB

ARCHITECTURE-SUMMARY.md

File metadata and controls

314 lines (222 loc) · 9.47 KB

Architecture Centralisée Obsidian - Stratégie Complète

🎯 Vision Stratégique

Évolution Historique du Projet

L'analyse de l'historique Git révèle 3 phases distinctes dans l'évolution de l'architecture :

  1. Phase 1 : Sample basique (9ef09bd)

    • Configuration ultra-simple d'Obsidian
    • Juste esbuild.config.mjs basique
    • Aucun script avancé

  2. Phase 2 : Scripts locaux élaborés (0fc65a6)

    • +622 lignes, -320 lignes = transformation majeure
    • Scripts personnalisés : acp.ts, esbuild.config.ts, release.ts, update-version.ts
    • Configuration TypeScript avancée

  3. Phase 3 : Architecture centralisée (1510573)

    • Suppression de tous les scripts locaux
    • Appels vers ../obsidian-plugin-config/scripts/
    • Dépendance "obsidian-plugin-config": "file:../obsidian-plugin-config"

🔍 Paradoxes Identifiés

1. Paradoxe de la centralisation

  • ✅ Avantage : Mise à jour centralisée, cohérence
  • ❌ Inconvénient : Dépendance locale obligatoire, pas d'injection à distance

2. Paradoxe des modifications locales

  • ✅ Besoin : Adapter la config à chaque plugin
  • ❌ Problème : Perte de la centralisation

3. Paradoxe de la complexité

  • ✅ Réalité : Même avec l'IA, setup complexe et long
  • ❌ Idéal : Configuration instantanée et simple

4. Paradoxe de la sauvegarde

  • ✅ Besoin : Conserver les configs qui marchent
  • ❌ Réalité : Difficile d'extraire la "bonne" config d'un plugin existant

🏗️ Architecture Actuelle

Structure obsidian-plugin-config

src/
├── modals/          # Composants modaux réutilisables
├── tools/           # Fonctions utilitaires simples
├── utils/           # Fonctions utilitaires avancées
└── index.ts         # Exports principaux
scripts/
├── esbuild.config.ts    # Configuration build centralisée
├── update-exports.js    # Auto-génération exports package.json
├── acp.ts              # Automatisation Git (add, commit, push)
├── migrate-config.ts   # CLI de migration automatique
└── update-version.ts   # Gestion des versions
templates/
├── package-versions.json  # Source unique des versions
├── eslint.config.ts      # Configuration ESLint standardisée
├── tsconfig.json         # Configuration TypeScript optimisée
├── .npmrc               # Protection yarn obligatoire
├── .vscode/settings.json # Settings VSCode pour yarn
└── .gitignore           # Règles git optimisées

🔗 Mécanisme de Résolution Actuel

// Dans le plugin template
import { showCentralizedModal } from "obsidian-plugin-config/modals";

Fonctionnement :

  1. Dépendance file: "obsidian-plugin-config": "file:../obsidian-plugin-config"
  2. yarn crée un symlink dans node_modules du template
  3. TypeScript résout les imports via package.json exports
  4. Le processus de build bundle tout correctement

⚠️ Limitation Critique Identifiée

Problème : Pour le développement in-place dans .obsidian/plugins, il faut :

cd .obsidian/plugins
git clone https://github.com/3C0D/obsidian-plugin-config
git clone https://github.com/3C0D/[votre-plugin]

Impact : Pollution du dossier plugins, contrainte de structure

🚀 Vision Future : Injection à Distance

🌐 Concept d'Injection à Distance

Objectif : Éliminer la dépendance locale en injectant les configurations directement depuis GitHub.

// Au lieu de file:../obsidian-plugin-config
// Injection directe depuis GitHub raw URLs
const configUrl =
  "https://raw.githubusercontent.com/3C0D/obsidian-plugin-config/main";

🎯 Avantages de l'Injection à Distance

  • ✅ Aucune pollution locale : Pas besoin de cloner plugin-config
  • ✅ Mise à jour instantanée : Toujours la dernière version
  • ✅ Sélection modulaire : Choisir quelles parties injecter
  • ✅ Développement in-place : Fonctionne partout sans contrainte
  • ✅ Zéro configuration : Installation immédiate

🔧 Mécanisme d'Injection Proposé

1. Script d'injection intelligent

# Injection complète
yarn inject-config

# Injection sélective
yarn inject-config --scripts --templates
yarn inject-config --only=esbuild,tsconfig

2. Système de templates multiples

obsidian-plugin-config/templates/
├── basic/           # Configuration simple
├── advanced/        # Configuration actuelle élaborée
├── svelte/          # Configuration Svelte
├── react/           # Configuration React
└── custom/          # Configurations sauvegardées

3. Gestion des modifications locales

// Système de patches locaux
const localPatches = {
  "tsconfig.json": { compilerOptions: { strict: false } },
  "package.json": { scripts: { custom: "my-command" } },
};

📦 Templates Configurables

Template Basic

  • Configuration minimale
  • Scripts essentiels (dev, build)
  • Dépendances de base

Template Advanced

  • Configuration actuelle complète
  • Tous les scripts (acp, release, version)
  • Protection yarn/npm
  • ESLint, TypeScript strict

Template Svelte

  • Configuration Svelte optimisée
  • Plugins esbuild spécifiques
  • Types Svelte

Template Custom

  • Configurations sauvegardées depuis plugins existants
  • Système de "snapshot" de configuration
  • Réutilisation sur nouveaux projets

🔄 Solution Hybride Optimale

🎯 Stratégie Recommandée

1. Injection à distance avec fallback local

try {
  // Tentative d'injection depuis GitHub
  await injectFromRemote(configUrl);
} catch (error) {
  // Fallback vers installation locale
  await useLocalConfig("../obsidian-plugin-config");
}

2. Système de snapshot de configuration

# Extraire la config d'un plugin qui marche
yarn snapshot-config ../working-plugin --name="my-custom-config"

# Réutiliser sur nouveau projet
yarn inject-config --template=my-custom-config

3. Gestion intelligente des mises à jour

# Mise à jour sélective
yarn update-config --preserve-local --only=scripts

# Mise à jour complète avec merge
yarn update-config --merge-local

📊 État Actuel de l'Architecture

✅ Fonctionnalités Opérationnelles

CLI de Migration Automatique

yarn migrate-config <path>           # Migration standard
yarn migrate-config --force <path>   # Re-migration avec sync versions
yarn migrate-config --dry-run <path> # Simulation
yarn migrate-config --interactive    # Interface guidée

Centralisation Maximale Réalisée

  • 100% des scripts centralisés
  • 100% des configurations centralisées (eslint, tsconfig, .npmrc, .vscode)
  • Réduction 60-80% des dépendances par plugin
  • Protection complète yarn/npm
  • Synchronisation automatique des versions

Résultats Quantifiés

Migration typique :
📦 Total dependencies: 37 → 8  (-78%)
📁 Local scripts: 6 → 0        (-100%)
💾 node_modules size: ~150MB → ~50MB (-67%)

🎯 Plugins Migrés avec Succès

  • ✅ obsidian-sample-plugin-modif : Template de référence
  • ✅ obsidian-vault-name-in-status-bar : Premier plugin migré
  • ✅ obsidian-duplicate-line : Plugin complexe avec fonctionnalités avancées

⚠️ Limitations Actuelles

Contrainte de Structure

  • Développement externe : Fonctionne parfaitement
  • Développement in-place : Nécessite clonage de plugin-config dans .obsidian/plugins

Gestion des Modifications Locales

  • Modifications dans plugin-config → Amélioration centralisée ✅
  • Modifications locales → Risque de perte lors des mises à jour ❌

🗺️ Roadmap Stratégique

📅 Phase 1 : Consolidation (Actuel)

  • CLI de migration automatique opérationnel
  • Templates centralisés complets
  • Protection yarn/npm robuste
  • Documentation stratégique unifiée
  • Message d'aide pour contrainte in-place

📅 Phase 2 : Injection à Distance (Futur Proche)

  • Développement du système d'injection GitHub
  • Templates multiples (basic, advanced, svelte)
  • Système de snapshot de configuration
  • Fallback intelligent local/distant

📅 Phase 3 : Industrialisation (Futur)

  • Interface web pour gestion des templates
  • CI/CD pour propagation automatique
  • Marketplace de configurations
  • Intégration VSCode extension

🎯 Recommandations Immédiates

Pour l'Utilisateur

  1. Continuer avec l'architecture actuelle pour nouveaux plugins
  2. Utiliser le CLI de migration pour plugins existants
  3. Documenter les contraintes dans les README des plugins
  4. Tester l'injection à distance sur un plugin pilote

Pour l'Architecture

  1. Ajouter message d'aide explicite pour développement in-place
  2. Créer templates spécialisés (Svelte, React)
  3. Développer système de snapshot pour sauvegarder configs
  4. Prototyper injection à distance avec GitHub raw URLs

💡 Conclusion Stratégique

L'architecture centralisée actuelle représente un équilibre optimal entre :

  • ✅ Fonctionnalité : CLI opérationnel, migration automatique
  • ✅ Simplicité : Commandes unifiées, protection automatique
  • ✅ Évolutivité : Base solide pour injection à distance
  • ⚠️ Contraintes : Limitation in-place documentée et contournable

Prochaine étape recommandée : Implémenter l'injection à distance pour éliminer définitivement la contrainte de structure locale.