L’erreur «Nom du module» se résout en un module non typé à… »lors de l’écriture du fichier de définition TypeScript personnalisé

89

Je ne trouve pas de définition TypeScript @type/{name}pour l'un de mes packages NodeJS installés, alors j'essaye d'écrire un d.tsfichier pour celui-ci et de placer le fichier dans un {project root}\typingsdossier. Voici comment je fais:

// My source code: index.ts
import Helper from 'node-helper-lib';


// My definition: \typings\node-helper-lib.d.ts
declare....(something else)

declare module 'node-helper-lib' {
   class Helper { ... }
   export = Helper;
}

Cependant, Visual Studio Code continue de générer cette erreur et place une ligne rouge sous declare module 'node-helper-lib':

[ts] Nom de module non valide dans l'augmentation. Le module 'node-helper-lib' se résout en un module non typé dans '{chemin du projet} \ node_modules \ node-helper-lib \ index.js', qui ne peut pas être augmenté.

N'est-il pas légitime que, parce que la bibliothèque n'est pas typée, je devrais être autorisé à y ajouter du texte?

MISE À JOUR:

J'utilise:

TypeScript: 2.1.4
Code Visual Studio: 1.9.1
Nœud JS: 6.9.4
Windows 10 x64

— hirikarate
source

151

La solution réelle est donnée dans un commentaire de @Paleo dans la réponse de @ hirikarate:

Les importations doivent être déclarées dans la déclaration du module.

Exemple:

declare module 'node-helper-lib' {
   import * as SomeThirdParty from 'node-helper-lib';
   interface Helper {
       new(opt: SomeThirdParty.Options): SomeThirdParty.Type
   }
   export = Helper;
}

— Lee Benson
source

21

Est-ce documenté quelque part?

— chris

12

Je ne sais pas combien d'heures il m'a fallu pour enfin trouver ça. Merci beaucoup! Cela devrait certainement être mieux documenté ...

— Jonathan Gruber

Pourquoi TypeScript n'a pas un bon message d'erreur ou quelque chose comme ça?

— VitorLuizC

53

Après quelques essais et erreurs, j'ai trouvé que cela augmentationsignifie "déclarer un module dans le même fichier avec d'autres déclarations de module".

Par conséquent, si nous voulons écrire un fichier de définition pour une bibliothèque JavaScript tierce non typée , nous devons en avoir UN SEUL declare module 'lib-name'dans ce fichier, et 'lib-name' doit correspondre exactement au nom de la bibliothèque (se trouve dans son package.json, " nom "propriété).

D'un autre côté, si une bibliothèque tierce a déjà un fichier de définition .d.ts inclus et que nous voulons étendre ses fonctionnalités, nous pouvons mettre la définition supplémentaire dans un autre fichier que nous créons. Cela s'appelle augmenting.

Par exemple:

// These module declarations are in same file, given that each of them already has their own definition file.
declare module 'events' {
   // Extended functionality
}

declare module 'querystring' {
   // Extended functionality        
}

declare module '...' { ... }

Je laisse ma découverte ici au cas où quelqu'un aurait la même question. Et veuillez me corriger si j'ai raté quelque chose.

— hirikarate
source

1

Que dois-je faire si une bibliothèque tierce contient déjà le fichier de définition .d.ts, mais que je souhaite l'ignorer et en utiliser un personnalisé?

— Alen Liang

24

J'essaie d'écrire un fichier de définition pour un module npm complètement non typé, supertest- La plainte de TypeScript n'a même pas de sens, comment puis-je ne pas augmenter quelque chose qui n'a même pas de déclaration? Je pensais avoir écrit des fichiers de définition personnalisés comme celui-ci plusieurs fois ...

[ts] Invalid module name in augmentation. Module 'supertest' resolves to an untyped module at '/home/chase/Desktop/projects/formuoli/node_modules/supertest/index.js', which cannot be augmented.

- malheureusement @types/supertestest cassé en incluant des bibliothèques DOM le rendant cassé .. on dirait que je n'ai pas de chance

— ChaseMoskal

34

@ChaseMoskal: Dans votre fichier .d.ts, vous devriez peut-être simplement déplacer toute l'importation dans le module de déclaration "moduleName" {}.

— Paleo

17

@Paleo c'était exactement ça, tous les importappels doivent entrer dans la declare module 'module' {}portée. l'erreur est au mieux trompeuse

— pocesar

2

typescript fait la même chose si vous mettez les importinstructions requises par votre module en dehors de au declare modulelieu de l'intérieur. Un tel comportement étrange et peu intuitif (désolé de déclamer ici).

— binki

0

J'avais aussi ce message d'erreur. Le problème pour moi était que j'essayais de déclarer un autre module dans un fichier de définition de type existant contenant une déclaration de module. Après avoir déplacé la nouvelle déclaration de module dans un nouveau fichier, l'erreur a disparu.

— G-Wiz
source

-4

Dans mon cas, je viens d'utiliser la déclaration suivante dans l'un de mes fichiers types, donc j'ai pu utiliser tous les packages non dactylographiés:

declare module '*'

— Alexey
source