Definitelytyped: Identifiant en double avec @types/node 10.0

J'étais sur le point d'enregistrer ce même problème !

J'ai essayé ceci :

npm init
npm i -g typescript
npm i --save-dev @types/node
tsc --init
touch index.ts
tsc

J'obtiens ces mêmes erreurs.

Ajout d'une mention supplémentaire pour le dernier auteur : @rbuckton.

Je vois aussi ça. La dernière poussée a cassé notre build avec cette même erreur.

Obtenir également ceci. Cela ressemble à un conflit avec Typescript dans mon cas.
Corrigé en rétrogradant à la version 9.6.7

Oui. Dans le message de l'OP, le conflit est avec lib.dom.d.ts . Je vois aussi des conflits avec lib.d.ts et lib.es2017.full.d.ts .

Ouais. voir ça aussi.

J'ai également rencontré ce problème, résolu en rétrogradant @types/node vers la version 9.6.7

Nous utilisons toujours le dernier LTS (8), nous avons donc résolu ce problème (pour l'instant) en utilisant ^8.0.0 .

Je pourrai regarder ça ce soir.

Vous pouvez vous faire une idée de l'impact de ce changement radical avec
La plupart des utilisateurs de TS incluent probablement @types/node ce qui est à l'origine de l'identifiant en double et de l' échec du CI .

@rbuckton Merci d'avoir examiné cela 👍

Solution rapide:

npm i @types/[email protected]

Pour les gars à l'ancienne avec nodejs v6.xx - npm i --save-dev @types/node@6

Cela a été cassé car ces classes ont été modifiées pour être exportées globalement, ligne 2380 dans le fichier actuel. Voir la comparaison de l'historique ci-dessous :

https://github.com/DefinitelyTyped/DefinitelyTyped/commit/bffb03282272b37ccb12429026f4504a39a3cd83#diff -7d84e08967cded0b99ed4328aab0a1a8

J'étais sur le point de tirer et d'apporter les modifications, mais il semble que @rbuckton soit déjà en avance sur moi dans le processus.

@robertbradleyux Dans le nœud 10.0.0, la classe URL est également disponible sur l'objet global , cela semble donc correct.

@rbuckton Existe-t-il un moyen de dire à TypeScript de ne définir la classe que si elle n'est pas déjà définie ?

Dans ce cas, le nœud et le navigateur implémentent le même standard d'URL WHATWG, ce qui est similaire à setTimeout qui a un type de retour différent dans Node.js que le navigateur https://nodejs.org/dist/latest -v10.x/docs/api/timers.html

D'une manière ou d'une autre, TypeScript est capable de gérer le setTimeout , il pourrait donc sûrement gérer l'URL globale, n'est-ce pas ?

Mise à jour Je vois qu'il y a déjà une pull request pour annuler ce changement https://github.com/DefinitelyTyped/DefinitelyTyped/pull/25356

Après avoir vidé mon cache npm, je reçois toujours l'erreur d'origine

@kgorlick Cela

@styfle , NodeJS et DOM ont de légères différences dans leurs implémentations de la norme d'URL WHATWG (par exemple, la version NodeJS a un toJSON() qui n'est pas dans la version DOM, et la version DOM a un createObjectURL statique

https://github.com/Microsoft/TypeScript/issues/23769

Je corrige temporairement le problème en ajoutant
"lib": ["es6"],
dans mon tsconfig.json

@rbuckton Je comprends qu'il peut y avoir des différences dans les définitions de URL .

setTimeout a un type de retour différent dans Node.js que le navigateur : docs

Pourtant, d'une manière ou d'une autre, inclure @types/node ne casse pas la construction. Comment ça marche ?

IIRC, les multiples versions des API de minuterie deviennent des surcharges. Le problème avec l'URL est qu'il s'agit d'un type d'objet.

J'ai eu cette erreur sur @11.9.3 et corrigée par :
npm i @types/[email protected] --save-dev

Obtenir cette erreur
avec "@types/node": "^11.9.4",

node_modules/@types/node/index.d.ts:75:15 - erreur TS2300 : identifiant en double 'SharedArrayBuffer'.

75 déclarer la classe SharedArrayBuffer {
~ ~ ~ ~~

node_modules/typescript/lib/lib.es2017.sharedmemory.d.ts:24:11
24 interface SharedArrayBuffer {
~ ~ ~ ~~
'SharedArrayBuffer' a également été déclaré ici.
node_modules/typescript/lib/lib.es2017.sharedmemory.d.ts:46:13
46 declare var SharedArrayBuffer: SharedArrayBufferConstructor;
~ ~ ~ ~~
et ici.

node_modules/@types/node/index.d.ts:83:15 - erreur TS2451 : impossible de redéclarer la variable à portée de bloc « personnalisée ».

etc.....

@Mulperi Je pense que votre problème est différent de ce qui précède et lié au changement de interface SharedArrayBuffer en class SharedArrayBuffer fait en #32878.

@SimonSchick Je pense que cela devrait être modifié car il ne s'agit en fait que d'une déclaration

@Flarna, cela ne fonctionnera que si vous chargez des typages dom, mais les typages de nœuds devraient fonctionner sans charger les typages dom.

Ce n'est pas dom c'est es2017.sharedmemory qui est inclus dans les typages 3.1 via /// <reference lib="es2018" /> mais les anciennes versions dactylographiées ne prennent pas en charge la directive reference lib .
La déclaration anticipée est utilisée pour éviter que tout le monde n'ait à l'inclure manuellement. Les déclarations directes doivent être un interface car les interfaces fusionnent avec les classes alors que les classes ne sont pas autorisées à être définies deux fois. Ainsi, l'utilisation de class pour une déclaration directe interrompt les builds là où la lib avec la définition réelle est incluse.

@Flarna ajouterait simplement /// <reference lib="es2017.sharedmemory" /> à /index.d.ts dans ce cas ?

Également pertinent car Atomics est toujours manquant dans ces saisies 🤔

Non, car /// <reference lib a été introduit dans tapuscrit 3.0 et le fichier affecté est celui qui est utilisé pour 2.1...3.0.
@Mulperi Quelle version dactylographiée utilisez-vous ? Je suppose que c'est <3.1.

J'ai aussi ce problème. Et passer à une version précédente de @types/node n'est pas une option réalisable, car @types/connect utilise * , extrait @^11.9 , et provoque des conflits dans la suite de tests.

@Flarna Je voyage actuellement, pourriez-vous peut-être vous

@jmeberlein Quelle version dactylographiée utilisez-vous ? Je suppose que c'est <3.1.

créé #33177. Difficile de dire quand cela a été fusionné car CI est actuellement dans un mauvais état.

Version dactylographiée ^2.9.2 dans package.json, résolue en 2.9.2 dans npm-shrinkwrap.json

pourquoi cette histoire est-elle fermée ? Il semble être encore cassé.

pourquoi cette histoire est-elle fermée ? Il semble être encore cassé.

Ce problème a été résolu il y a près d'un an, il semble donc qu'il ait été corrigé, mais qu'il a maintenant régressé. J'ouvrirais probablement un nouveau sujet.

ng] ERROR in node_modules/@types/node/index.d.ts:73:11 - error TS2300: Duplicate identifier 'IteratorResult'. [ng] 73 interface IteratorResult<T> { } [ng] ~~~~~~~~~~~~~~ [ng] node_modules/typescript/lib/lib.es2015.iterable.d.ts:41:6 [ng] 41 type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>; [ng] ~~~~~~~~~~~~~~ [ng] 'IteratorResult' was also declared here. [ng] node_modules/typescript/lib/lib.es2015.iterable.d.ts:41:6 - error TS2300: Duplicate identifier 'IteratorResult'. [ng] 41 type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>; [ng] ~~~~~~~~~~~~~~ [ng] node_modules/@types/node/index.d.ts:73:11 [ng] 73 interface IteratorResult<T> { } [ng] ~~~~~~~~~~~~~~ [ng] 'IteratorResult' was also declared here.

Problème toujours pas résolu

@thameurr Veuillez noter que vous commentez un problème fermé il y a un certain temps. Je suppose que vous utilisez un ensemble de versions @types/node, tapuscrit,... différent de ceux mentionnés dans ce numéro.

Pourriez-vous créer un nouveau problème avec des instructions sur la façon de reproduire où les versions à jour des packages sont utilisées ?

J'ai eu ce problème avec @types/node: "13.9.5" et il a été résolu en revenant à "12.12.31" 🤷‍♂️

Type error: Duplicate identifier 'ProcessEnv'

Ce problème se produisait toujours pour moi avec TypeScript 4.0.2. L'installation de @types/node à la version 14.6.0 semblait faire disparaître les erreurs lors de l'exécution de tsc --noEmit .