Je suis d’accord. Comme je l’ai indiqué, il s’agissait d’une première version, qui a été améliorée grâce à vos retours. Nous avons jeté un autre regard et vous aviez raison.
Ajouté à la méthode de revue
-
Classification des candidats avant l’inspection des fichiers :
- Plugin
- Thème
- Composant de thème
- Extension hybride
- Dépôt d’intégration
- Artefact de publication
-
Inventaire séparé du dépôt partagé / de la publication :
- README, licence, journal des modifications (changelog)
- Fichiers de paquet et fichiers de verrouillage (lockfiles)
- Flux de travail CI
- Scripts d’installation / Docker
- Intégrations de services externes
- Assets de publication générés
- Publication avec étiquette / archivée
- Fichiers non suivis et ignorés pertinents
-
Inventaire des plugins étendu :
- Chaque fichier chargé, enregistré ou exposé par
plugin.rb config/routes.rbdb/post_migrate/- Vues, moteurs, validateurs et middleware
- Code frontend d’administration et public
- Connecteurs, composants, routes, services, modèles et tests frontend
- Styles communs, bureau, mobile, administration et intégrés
- Fixtures, fichiers de support et tests navigateur / système
- Dépendances Ruby, JavaScript, système et services externes
.discourse-compatibility- Branches et flux de travail
d-compat/* - Bornes de version Discourse déclarées
- Chaque fichier chargé, enregistré ou exposé par
-
Nouvel inventaire de thème / composant de thème :
about.jsonà la racine- Classification
component - Métadonnées de licence, auteur, version et compatibilité
- Assets, schémas de couleurs, captures d’écran et réglages thémables déclarés
settings.ymlà la racinelocales/à la racinecommon/,desktop/etmobile/- Fichiers SCSS et fichiers d’injection HTML pris en charge
javascripts/à la racineapi-initializers/- Tous les fichiers
.js,.gjset.hbs stylesheets/à la racine et feuilles de style importéesassets/à la racine et toutes les références à ceux-ci- Aperçus / captures d’écran
- Tests et configuration de lint / build
- Métadonnées et branches de compatibilité
- Octets du thème empaqueté / exporté
-
Nouvelles vérifications structurelles :
- Le type d’extension déclaré doit correspondre à
about.jsonet au comportement d’installation. component: truesignifie composant de thème.component: falseou omis signifie thème complet.- Les dépôts hybrides reçoivent tous les inventaires applicables.
- Les fichiers mal placés ou inattendus sont investigués plutôt qu’ignorés silencieusement.
- L’absence de dossiers optionnels n’est pas automatiquement un défaut.
- L’arborescence de travail, l’archive de publication, l’extension installée, les assets générés et le candidat public sont des surfaces de preuve distinctes.
- Le type d’extension déclaré doit correspondre à
-
Nouvelle liste de contrôle pour thème complet :
- Identité des métadonnées
- Rendu du thème complet
- Couverture des pages principales
- Réglages, localisations et assets
- Initialisateurs JavaScript / API pris en charge
- Comportement responsive, accessibilité et RTL
- Comportement Foundation, Horizon et intégré
- Interactions avec les composants de thème
- Vérifications d’installation, de mise à jour, de retour arrière et de compatibilité
Mon espoir est que les retours de la communauté améliorent la compétence (Skill) et que cette compétence aide les autres à évaluer leur propre travail ou, franchement, le travail des autres avant l’installation, en cas de doute quant à la qualité.
Jusqu’à présent, nous sommes à 2 sur 2. Vos retours ont permis d’améliorer la compétence et @satonotdead l’a trouvée utile. Merci pour vos mots gentils et votre soutien @satonotdead