FigmaToCode : générer des pages et applications responsives dans le bac à sable du plugin Figma

À quoi sert ce projet

FigmaToCode vise le moment entre un design visuel et une implémentation réelle. Un utilisateur sélectionne un cadre, un composant ou un groupe de calques plus petit, et le plugin produit un échafaudage visuel lisible qui peut être copié, affiné ou téléchargé comme projet de démarrage. La conversion est déterministe et s'exécute entièrement dans le bac à sable du plugin Figma. Selon le README, il n'appelle pas de modèle d'IA, n'inspecte pas de dépôt et n'envoie pas la sélection à un autre service, ce qui le rend utile pour les transferts rapides ainsi que pour les équipes où le traitement externe des designs n'est pas autorisé.

Cibles de sortie et projets de démarrage

Le plugin prend en charge quatre cibles principales. La cible HTML propose les modes HTML, React (JSX), Svelte et styled-components. La cible Tailwind CSS propose les modes HTML, React (JSX) et Twig, avec prise en charge de Tailwind 3 et Tailwind 4. La cible Flutter peut produire une application complète, un widget sans état ou un extrait. La cible SwiftUI peut produire un aperçu, une structure View ou un extrait. Le plugin peut également empaqueter le code généré et les ressources image locales dans des téléchargements de démarrage : Vite, Next.js ou HTML statique pour le web ; source Flutter avec pubspec.yaml, ressources et instructions d'installation ; et source SwiftUI avec catalogue de ressources et instructions d'installation. Le README précise que ces exports sont délibérément petits et légers en dépendances, et qu'ils sont des points de départ plutôt que des applications de production générées.

Ce qui peut être réglé

Les options n'apparaissent que lorsqu'elles s'appliquent à la cible sélectionnée. L'utilisateur peut choisir d'inclure les noms de calques Figma dans les classes générées, de conserver les valeurs exactes ou d'arrondir les espacements et couleurs aux jetons Tailwind proches, de générer la syntaxe Tailwind 4 et d'ajouter un préfixe de classe personnalisé, d'utiliser les variables de couleur Figma dans les sorties prises en charge, d'intégrer les images en Base64 dans le HTML, d'intégrer les formes vectorielles prises en charge en SVG pour le web, et de basculer entre les modes fichier, composant et extrait spécifiques au framework. L'interface comprend également un aperçu visuel, des arrière-plans d'aperçu clair et sombre, des avertissements de conversion, des couleurs et dégradés extraits, la copie de code et les téléchargements de projet.

Comment l'utiliser

Le README décrit le flux d'utilisation comme suit : installer Figma to Code depuis la communauté Figma, sélectionner un cadre, un composant, un groupe ou un calque individuel, exécuter le plugin dans Figma Design ou choisir l'une de ses sorties codegen en mode Dev, choisir une cible et ajuster les options pertinentes, puis examiner l'aperçu et les avertissements avant de copier le code ou de télécharger un projet de démarrage. Le README conseille que les sélections plus petites créent généralement de meilleures limites de composants, et suggère de générer une section ou un contrôle réutilisable plutôt que de convertir une page entière à la fois.

Modèle de confidentialité

Le manifest.json au niveau du dépôt est la configuration que Figma utilise pour le plugin publié, et il contient une limite exécutoire : permissions est vide et networkAccess.allowedDomains est ['none']. Les nœuds sélectionnés sont lus via l'API Plugin de Figma, normalisés en mémoire, convertis par du code TypeScript spécifique au framework et renvoyés à l'interface du plugin. Le README indique qu'il n'y a pas de télémétrie, pas de téléversement de design, pas de modèle externe et pas de compte utilisateur séparé. Il note également que cette affirmation est volontairement étroite : Figma lui-même est un produit connecté et traite les fichiers selon le plan et les politiques Figma de l'utilisateur, mais ce plugin n'ajoute pas une autre destination réseau pour les données de design sélectionnées.

Ce qu'il gère bien et ce qu'il ne fait pas délibérément

Le README liste comme points forts du plugin Auto Layout, les cadres imbriqués, les groupes, l'alignement, le dimensionnement et l'empilement ; le flux mixte et le positionnement absolu ; la typographie, les remplissages, les bordures, les rayons de coins et de nombreux effets ; les variables de couleur et plusieurs types de dégradés ; l'export d'images et de ressources locales ; et les échafaudages visuels responsives sur les cibles web et natives. Il liste ensuite les limitations délibérées : pas d'inférence IA, donc il n'invente pas de sémantique, d'interactions ou de refontes basées sur des invites ; pas de connexion à une base de code, donc il ne peut pas inspecter un dépôt, mapper des composants existants, importer une application dans Figma, synchroniser des fichiers générés ou pousser des modifications de design ultérieures dans le code ; pas de logique applicative, donc il ne peut pas déduire la gestion d'état, le chargement de données, la navigation, le comportement backend ou les règles métier ; et pas d'accessibilité inventée, donc la sémantique, les étiquettes, le comportement clavier, le type dynamique et les points de rupture responsives nécessitent toujours une revue humaine. Certains détails dépendent de la cible, par exemple la prise en charge vectorielle est optionnelle pour le web et limitée dans les cibles natives, et les grandes sélections coûtent plus de mémoire.

Pipeline de conversion et développement local

Le processus de conversion est décrit comme ressemblant plus à un petit compilateur qu'à un service de capture d'écran vers code. Il lit les nœuds Figma sélectionnés et leurs métadonnées de mise en page et de style, les normalise dans un arbre interne sans modifier le document source, optimise les relations parent-enfant, Auto Layout, l'alignement, le dimensionnement et le positionnement, envoie l'arbre normalisé au backend HTML, Tailwind, Flutter ou SwiftUI sélectionné, et renvoie le code, les données d'aperçu, les ressources extraites et les avertissements de conversion. Parce que les règles sont du TypeScript public, la conversion peut être inspectée, testée et améliorée sans dépendre d'une API hébergée. Pour le développement local, le README liste Node.js 24 ou plus récent et pnpm 11 comme prérequis, avec pnpm install à la racine du dépôt, pnpm dev pour lancer les watchers du plugin et le site web du produit sur http://localhost:3000, et pnpm --filter plugin dev pour travailler uniquement sur le plugin. Les autres commandes sont pnpm build, pnpm lint, pnpm test, pnpm format et pnpm format:check. Le dépôt est divisé en packages/backend pour le traitement des nœuds, la représentation intermédiaire, les générateurs de code et les exports de projet ; packages/plugin-ui pour l'interface React partagée ; packages/types pour les types partagés de paramètres, messages, aperçus et sorties ; packages/tsconfig pour la configuration TypeScript partagée ; apps/plugin pour le contrôleur Figma et les points d'entrée UI ; et apps/web pour le site public, l'aperçu interactif, la page de confidentialité et les guides de comparaison.

Conclusion éditoriale

FigmaToCode effectue la conversion du design vers le code dans le bac à sable du plugin Figma, produit des sorties HTML, Tailwind, Flutter et SwiftUI et les empaquette dans de petits projets de démarrage. Il n'appelle délibérément aucun modèle d'IA, ne se connecte pas à une base de code, n'infère pas de logique applicative et ne revendique pas de sémantique d'accessibilité générée ; lorsqu'un détail ne peut pas être traduit proprement, il affiche un avertissement.

Sources officielles

1. Official documentation
2. Official README
3. Project repository