Série SPFx : Structure du projet

La structure du projet d’un projet SharePoint Framework (SPFx) est conçue pour fournir une manière cohérente et épurée d’organiser votre code et vos fichiers. Voici une structure de projet standard, avec quelques exemples des principaux dossiers et fichiers que vous pourriez voir dans un projet SPFx :

Dossier .vscode

Le dossier par défaut créé par Visual Studio. Ces fichiers contiennent les configurations de débogage et de tâches. Ce dossier contient trois fichiers comme ci-dessous :

extensions.js : Ce fichier n’est pas lié à SPFx. Il indique uniquement la liste des extensions que vous avez installées dans votre VS Code.
launch.json : Ce fichier contient les configurations du Workbench. Nous pouvons définir l’emplacement pour le Workbench local et hébergé par SharePoint. Mais le Workbench SPFx a été déprécié depuis la version 1.12.1.
settings.json : settings.json n’est pas lié à SPFx et ce fichier définit les préférences utilisateur telles que les espaces, la taille de police du code, etc. Vous pouvez ignorer ce fichier car il n’est pas important.

Répertoire de configuration

Ce dossier contient un ensemble de fichiers JSON qui nous aident à définir les configurations pour notre solution SPFx. Ces configurations incluent les points d’accès des WebParts, la page d’accueil du Workbench, etc. Le dossier de configuration contient tous les fichiers JSON comme ci-dessous.

config.json : C’est l’un des fichiers principaux de la solution SPFx. Il contient une liste de tous les WebParts présents dans votre solution. Point de départ pour chaque WebPart : afin que le WebPart sache exactement par où commencer - Emplacement du fichier manifest pour chaque WebPart : le fichier manifest contient toutes les informations sur les WebParts telles que l’ID du WebPart, le nom, la description, etc. - Emplacement des ressources localisées pour chaque WebPart : les ressources localisées servent votre WebPart dans différentes langues.
Vous pouvez également définir les fichiers JS externes si vous souhaitez qu’ils soient chargés avec votre solution. Par exemple, vous pouvez placer le chemin des fichiers jQuery comme indiqué ci-dessous sous externals comme indiqué dans l’image ci-dessous :

copy-assets.json : Si vous souhaitez héberger votre WebPart à l’aide d’un CDN, vous pouvez utiliser ce fichier. Ici, nous définissons le chemin CDN des fichiers js générés lors de l’exécution de la commande bundle. Vous pouvez ensuite accéder à ce chemin depuis votre solution et copier les fichiers .js vers le CDN.
deploy-azure-storage.json : C’est le fichier qui contient les informations de votre compte de stockage Azure. Les WebParts SPFx sont principalement déployés sur l’une des options CDN (Content Delivery Network) suivantes : Azure CDN - Office 365 Public CDN
Bibliothèque SharePoint dans votre tenant
Lorsque vous devez déployer votre WebPart sur Azure CDN, vous devez configurer les détails du compte de stockage Azure dans ce fichier JSON.
package-solution.json : Ce fichier contient des détails sur l’emplacement du package généré lors de la construction de la solution. Ce fichier contient également les configurations telles que le nom du WebPart, la description, les fonctionnalités de version, le nom du fichier zippé, etc.
serve.json : Ce fichier contient l’URL pour charger la première page lorsque vous exécutez le WebPart à l’aide du Workbench local.
write-manifests.json : Vous pouvez spécifier le chemin CDN si vous avez décidé d’héberger le CDN externe de l’application SPFx autre que le CDN public Office 365.

Node_modules

Comprend les modules JavaScript téléchargés par Node.js.

Lorsque nous exécutons l’installation npm, tous les modules externes requis seront téléchargés et stockés dans le dossier node_modules. Ce dossier est uniquement nécessaire à des fins de construction. Nous ne validons pas ce dossier dans le référentiel car ce n’est pas un dossier personnalisé. Lorsque nous clonons le référentiel et exécutons la commande npm install, ce répertoire sera créé avec tous les modules requis.

Tous les modules externes requis que nous utilisons dans notre solution sont définis dans le fichier package.json.

npm install

src

C’est le dossier source réel où notre code de WebParts et d’extensions est placé. Sous le dossier src, vous trouverez le dossier WebPart pour les WebParts et le dossier extension pour les extensions.

loc : Ce répertoire contient un fichier d’interface et un ou plusieurs fichiers de localisation de langue tels que en-us.js, nl-NL.js, etc. SPFx offre la possibilité de charger le WebPart dans différentes langues. Vous pouvez définir les séquences de langue dans ces fichiers.
webpart.manifest.json : Chaque WebPart possède son propre fichier manifest. Il contient la configuration relative au nom du WebPart, la description du WebPart, le nom du groupe, l’icône du WebPart, etc.
webpart.module.scss : C’est un fichier de style pour votre WebPart. C’est ce qu’on appelle SCSS (Sassy CSS), qui est une version avancée de CSS.
webpart.ts : Ce fichier définit le point de départ pour le WebPart. Ce fichier contient une classe WebPart qui étend BaseClientSideWebPart. BaseClientSideWebPart prend en charge le fonctionnement de base du WebPart. Ce fichier contient également les configurations du panneau de propriétés du WebPart.
Dossier Components : Ce dossier n’est disponible que si vous utilisez React comme framework. Ce dossier contient les fichiers d’interface d’état et de props, le fichier .scss, et un fichier important connu sous le nom de webpart.tsx.

webpart.tsx : Ce fichier contient principalement le HTML de votre WebPart. Il inclut également l’appel de fonction avec le cycle de vie React. À l’aide de ce fichier, vous pouvez mettre à jour l’état du WebPart. Ce fichier n’est disponible que si vous utilisez React dans votre WebPart.

Autres fichiers

.gitignore : Ce fichier contient tous les fichiers qui doivent être ignorés par git. Cela signifie que lorsque vous validez le code, les fichiers mentionnés dans ce fichier seront ignorés et ne seront pas chargés dans le référentiel.
.yo-rc.json : Lorsque nous exécutons le générateur Yeoman sur une nouvelle carte, le projet et les composants sont créés. Ce fichier indique la version de Yeoman et l’environnement que nous avons utilisé pour créer la solution. Cette version est également connue sous le nom de version SPFx. Si vous l’exécutez à nouveau, il détecte (grâce à la présence du fichier .yo-rc) et saute toutes les questions générales sur le projet pour aller directement aux questions pour la création d’un nouveau composant.
gulpfile.js : Les tâches Gulp que nous utilisons pour exécuter l’application sont définies dans ce fichier.
package-lock.json : Il stocke un arbre de dépendances exact avec des versions au lieu d’utiliser un contrôle de version avec des caractères génériques comme package.json lui-même (par ex. 1.0.*). Cela signifie que vous pouvez garantir les dépendances pour d’autres développeurs ou les versions de production, etc. Il dispose également d’un mécanisme pour verrouiller la structure de l’arbre, mais sera généralement régénéré si package.json change.
package.json : Ce fichier contient plusieurs métadonnées pertinentes pour le projet. Ce fichier est utilisé pour fournir des informations à npm qui lui permettent d’identifier le projet et de gérer les dépendances du projet.

Il peut également inclure d’autres métadonnées telles qu’une description du projet, la version du projet dans une distribution particulière, des informations de licence, voire des données de configuration — tout cela peut être vital pour npm et les utilisateurs finaux du package.

tsconfig.json : La présence du fichier tsconfig.json dans un dossier indique que le dossier est la racine d’un projet TypeScript. Le fichier tsconfig.json spécifie les fichiers racines et les options du compilateur nécessaires pour compiler le projet.
eslint.json : ESLint vérifie le code TypeScript pour la lisibilité, la maintenabilité et les erreurs de fonctionnalité. Nous pouvons définir les règles pour lesquelles le code vérifie les avertissements et les erreurs de build.