Déclaration de module dans TS

Ici, nous apprenons à écrire un fichier de déclaration Typescript de haute qualité. Vous codez donc dans ReactJS et souhaitez importer un fichier SVG mais votre IDE/tsc se plaint.

[ts] cannot find module './logo.svg'

C'est le moment de se tourner vers Stackoverflow pour une solution de copier-coller rapide.

Mais tenons le coup et essayons de comprendre ces fichiers et ce qu'ils font pour nous pendant une seconde.

Qu'est-ce qu'un module ?

Dans TS/JS, nous avons eu de nombreuses approches pour modulariser nos applications écrites en TS/JS. Actuellement, ce qui règne en maître, c'est l'ESM (modules AKA ES, modules ES6). Nous les connaissons généralement avec leur syntaxe :

Donc, pour répondre à la question d'origine, en TS/JS conformément à ECMAScript 2015, tout fichier contenant une importation ou une exportation de niveau supérieur est considéré comme un module.

Et si l'on n'a pas d'import ou d'export de premier niveau :

1. Ils sont disponibles partout.
2. Ils sont traités comme des scripts.

Pourquoi utiliser des modules ?

Plus de pollution globale des espaces de noms. Cela implique que :

1. Les modules sont exécutés dans leur propre périmètre.
2. Nous devons exporter explicitement tout ce que nous voulions exporter.
3. Le consommateur peut importer depuis un module différent ce qu'il a exposé aux autres.

Exportations nommées et exportations par défaut

Résolution des modules

Dans le module TS, la résolution consiste à extraire une chaîne de l'instruction import ou require et à déterminer à quel fichier cette chaîne fait référence.

Dans TS, nous avons deux stratégies :

1. Classique :
   • Celui par défaut.
   • Le compilerOptions.module n'est pas "CommonJS".
   • Inclus pour une compatibilité ascendante.
2. Nœud :
   • Réplique le fonctionnement de NodeJS en mode CommonJS.
   • Vérifications supplémentaires pour les fichiers .ts et .d.ts.

BTW, nous avons des tonnes d'endroits où nous pourrions le modifier intentionnellement ou non (moduleResolution, baseUrl, paths, rootDirs).

moduleRésolution

• Contrôle la manière dont TS résout les spécificateurs de module (ces chaînes littérales dans les instructions import/export/require) en fichiers sur le disque.
• Doit être défini pour correspondre au résolveur de module utilisé par le runtime ou le bundler cible.

Par exemple, si vous créez votre application pour utiliser ESM (la version compilée utilise ESM), vous devez alors choisir "NodeNext" dans votre compilerOptions.module.

• Tant que nous utilisons une extension de fichier de chemin relatif, TS peut la résoudre (par exemple, importer {} depuis "./a.js" ; // ✅ Fonctionne dans chaque résolution de module).
• Si vous envisagez de compiler votre application pour utiliser ESM, vous devez spécifier l'extension des fichiers et ne pouvez pas utiliser une extension sans extension (par exemple, importer {} depuis 'a.mjs';).
• Vous pouvez également importer un répertoire qui devrait contenir un fichier index.ts.

Remarque : si à l'intérieur de ce répertoire, vous avez un package.json. Ensuite, TS utilise son principal et ses types pour récupérer ses types.

En savoir plus ici.

chemins

Donc, fondamentalement, il remappe les importations vers l'emplacement de recherche*s* par rapport à baseUrl s'il est défini, sinon vers le fichier tsconfig. Le cas d'utilisation le plus courant est celui des alias de chemin :

[ts] cannot find module './logo.svg'

Attention

Cela ne veut rien dire pour le runtime. Cela signifie que votre cher bundler ou compilateur doit prendre soin de les regrouper correctement. Et si votre chemin pointe vers un endroit qui n'existe pas, votre application plantera lors de son exécution par NodeJS.

Conseil

Au lieu de cela, vous pouvez utiliser les importations de package.json (importations AKA Subpath).

URL de base

• Répertoire de base à partir duquel résoudre le spécificateur nu¹ noms de modules
• A une priorité plus élevée que les recherches de node_modules.
• Il n'est plus nécessaire de le définir lors de l'utilisation de chemins.

répertoires racines

• De nombreux répertoires « virtuels » agissant comme une seule racine.
• Ensuite, le compilateur peut résoudre les importations relatives de modules dans ces répertoires "virtuels", comme s'ils étaient fusionnés en un seul répertoire.

JS compilé

Pour affecter la sortie JS émise, nous pouvons modifier :

• compilateurOptions.cible :
  • Détermine quelles fonctionnalités JS sont converties pour être exécutées dans des environnements d'exécution JavaScript plus anciens.
  • Dicté par les exigences de notre application, par exemple sur quel navigateur/NodeJS/Electron je vais exécuter ce code TS compilé.
• compilateurOptions.module :
  • quel module d'exécution du système utilisera.
  • Utilisez "nodenext" pour les projets NodeJS modernes. Il lit le fichier package.json le plus proche et utilise sa valeur "type" pour décider s'il doit opter pour CommonJS ou ESM.
  • Utilisez "esnext" lorsque vous allez le regrouper avec un bundler.

Retour au sujet principal

Nous voulons donc importer un fichier .graphql ou une autre extension dont TS n'a aucune idée de à quoi ils ressemblent (il ne peut pas résoudre leurs types). Alors maintenant, TS sait à quoi ressemblera un fichier svg, graphql ou autre importé.

---

réf.

---

---

1. Spécificateur nu : un nom de module dans une instruction d'importation qui n'est PAS un chemin relatif ou absolu. Il s'agit généralement de noms de packages dans les node_modules de votre projet ou dans d'autres emplacements configurés. ↩

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!