Definitelytyped: @types/core-js rompt la construction de la version 0.9.37

Nous recevons également beaucoup d'erreurs ici. (Impossible de trouver le nom "Promise", Impossible de trouver le nom "Set", ...)
Revenir à 0.9.36 résout le problème pour nous en ce moment.

@andy-ms / @mhegazy

"Définitions par" dit @rbuckton , mais aucune réponse là-bas. Je vois que le dernier commit est fait par vous. Des commentaires ?

Si ce n'est pas @rbuckton qui est responsable, peut-être mettre à jour index.d.ts avec le responsable droit ?

Essayez de définir --lib dans votre tsconfig pour obtenir les définitions dont vous avez besoin.

@andy-ms Je ne suis pas très familier avec le compilateur de typescript, il est interne et comment il utilise la bibliothèque de types, donc je ne sais pas trop quoi définir dans la section lib ici? Et pourquoi? S'il vous plaît donnez votre avis.

@dozer75 consultez ce lien : [typescript compiler options].(https://www.typescriptlang.org/docs/handbook/compiler-options.html)

Si vous modifiez votre fichier tsconfig.json, ajoutez une propriété de lib avec un tableau de chaînes spécifiant les bibliothèques à inclure. Pour moi, j'utilisais @types/core-js dans un environnement de serveur de nœuds (avec la cible es5, c'est-à-dire que mon script était compilé en es5 pour la production) alors j'ai juste ajouté "es2015" et tout a bien fonctionné. Il semble que si vous êtes dans un environnement de navigateur, l'ajout de "dom" vous donnera un javascript standard window et des trucs comme ça aussi.

En ajoutant

"lib": ["es2017", "dom"]

à mon compilerOptions dans tsconfig.json résolu ce problème pour moi.

merci @andy-ms

La documentation dactylographiée
@Narven lors de l'ajout d'es2017 à votre bibliothèque, vous n'avez plus besoin de frappes core-js. Je me demande pourquoi vous n'obtenez pas d'identifiants en double alors.

Je ne comprends pas pourquoi les typages core-js dépendent soudainement d'un autre ensemble de bibliothèques. Cela ne me semble pas la bonne solution.

@DaSchTour Je pense que lib: ["dom", "es5", "scriptHost"] est la valeur par défaut utilisée pour la cible es5 si vous ne spécifiez pas vous-même de propriété lib . C'est du moins ce que je comprends, et ce serait la raison pour laquelle vous n'obtenez pas d'identifiants en double lorsque vous spécifiez vous-même lib: ["es2015", "dom"] .

De plus, l'option lib remplace l' utilisation de @types/core-js par opposition à une dépendance.

@DrDanRyan ce n'est certainement pas un remplacement ! lib pour ES2017 contiendra bien plus que @types/core-js qui masquera les erreurs de compilation lors de l'utilisation de fonctionnalités non polyremplies par core-js

C'est pourquoi j'utilise "es2015" qui fonctionne pour un serveur de nœuds...

Le problème existe toujours. lib contient plus de core-js donc je ne pense pas que les frappes pour core.js devraient "étendre" lib .

Je pense que nous nous parlons ici. Tout ce que je dis, c'est qu'après avoir mis lib: ["es2015"] dans mon tsconfig.json que je n'ai plus besoin d'utiliser @types/core-js , je l'ai donc désinstallé et maintenant j'utilise simplement le drapeau du compilateur.

Relier cela avec PR qui a causé cela : https://github.com/DefinitelyTyped/DefinitelyTyped/pull/15108

Mettre lib: ["es2015"] n'a pas résolu le problème pour moi.

je reçois toujours

error TS2693: 'Promise' only refers to a type, but is being used as a value here.

J'ai essayé de tout ajouter :

  "lib": [
    "es5",
    "es2015",
    "es2017",
    "dom",
    "scripthost"
  ],

et toujours l'erreur

Pouvez-vous fournir le code qui échoue?

J'ai fini par le résoudre comme ceci :

{
  "compilerOptions": {
    "target": "es6",
    "module": "es6",
    ...
  },
  "lib": [
    "ES5",
    "ES2015",
    "DOM",
    "ScriptHost"
  ]

et en supprimant @types/core-js

@dmitriid ne sait pas pourquoi, mais la même valeur de lib a fonctionné pour moi.

Voici mon tsconfig complet.

{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "es5",
      "es2015",
      "es2017",
      "dom",
      "scripthost"
    ],
    "module": "commonjs",
    "experimentalDecorators": true,
    "sourceMap": true
  }
}

J'ai probablement résolu mon problème et récupéré mon vote positif du message d'origine.

L'utilisation de la configuration "lib" est-elle la bonne solution à long terme, ou @types/cores-js sera-t-il corrigé afin qu'il puisse être utilisé de la même manière que précédemment ?

@PrimalZed Je ne pense pas que l'utilisation de lib soit une solution appropriée, car elle introduit des fonctionnalités qui pourraient ne pas être disponibles via core-js. Ainsi, lib et @types/core-js ne contiendront jamais le même ensemble de méthodes et core-js contiendra toujours moins que lib.

@DaSchTour regardons l'exemple :

• Il existe une bibliothèque X , qui utilise ES6 Map et qui est tapée à l'aide des définitions de la lib es6
• Afin de prendre en charge les anciens navigateurs, vous avez importé core-js polyfill dans votre code avant d'importer X .

Les bibliothèques tierces ne savent rien de la mise en œuvre réelle de polyfill, donc polyfill devrait fournir des définitions identiques afin d'éviter des bogues comme celui-ci https://github.com/DefinitelyTyped/DefinitelyTyped/issues/15104

@just-boris et puis il y a le projet Y et tout en utilisant core-js et en compilant vers es5 avec es6 lib, un développeur voit que les chaînes ont une fonction appelée normaliser. Super 🎉 utilisons-le, c'est exactement ce que je cherchais. Et quelques semaines plus tard, en testant sur IE11 et Safari 9, nous constatons des erreurs étranges que nous espérions éviter en utilisant TypeScript 🤔
Oh et du coup, nous pouvons utiliser Proxy avec ES5 sur IE11. Agréable!
Ainsi, polyfill doit implémenter une prise en charge complète et à 100% de l'ES6 pour éviter les bogues et permettre une utilisation sûre. 100%, 99,999%, c'est moins, car lib révélera des fonctionnalités qui ne sont pas polyremplies. Alors disons au revoir core-js 😢

De mon côté, j'ai fini par passer à @types/ core - 0.9.37 et mettre à jour mon tsconfig vers celui-ci, gardant ainsi la compatibilité avec IE 11.

"lib": [
      "dom",
      "dom.iterable",
      "es2015",
      "scripthost"
    ],

En ajoutant

"lib": ["es2017", "dom"]

à mon compilateurOptions dans tsconfig.json a résolu ce problème pour moi.

merci @Narven

@just-boris votre commentaire a fonctionné pour moi, ty !

J'ai besoin que cela fonctionne pour "cible es5", utiliser lib est un hack et a juste une mauvaise odeur dans l'ensemble.

La méthode suggérée consiste à utiliser @types/core-js, ce qui ne fonctionne malheureusement pas pour un code simple comme

let p = Promise.resolve( [ 1, 2, 3 ] );
p.then( function( v ) {
  console.log( v[ 2 ] ); // 1
} );

@andy-ms / @mhegazy
Si je peux me permettre, j'aimerais refaire surface écrit sur #15108 :

Le but des fichiers de définition Typescript n'est-il pas de décrire ce que les packages fournissent ? Je pense que la définition doit être précise pour l'emballage, pas pour l'environnement. En particulier avec core-js, si quelqu'un l'utilise, par exemple, importe 'core-js', il le fait probablement parce qu'il modifie son environnement, non ?

Une raison importante pour laquelle les gens utilisent des définitions de type est de faire apparaître des problèmes au moment de la compilation plutôt qu'au moment de l'exécution. Il est en fait très important que les définitions de core-js représentent ce que core-js fait spécifiquement parce qu'il ne fournit core-js que les bibliothèques d'environnement doivent être une affaire distincte, c'est-à-dire que le polyfill peut ne pas correspondre à la norme.

Générer des changements de rupture entre les projets en raison de changements comme celui-ci ne peut pas être pris à la légère comme démontré ici. D'une part, il est déjà assez difficile de suivre l'impact de la mise à niveau des packages

J'ai pu corriger mon erreur de compilation en ajoutant ce qui suit à mon tsconfig.json .

    "target": "es5",
    "lib": ["es2015", "dom"]

Ce qui est vraiment stupide à propos de cette solution, c'est que sans inclure "dom", TypeScript produira une erreur lorsque Promise est utilisé.

Vous pouvez également obtenir ces erreurs si votre build n'est pas configuré correctement.

J'utilise gulp + gulp-typescript et je n'ai pas configuré le processus de création de typescript pour prendre en compte tsconfig.json.

Essayez donc ceci :

gulp.task('typescript', function () {
  var tsProject = ts.createProject(`${sourceRoot}/tsconfig.json`);
  return gulp.src([`${sourceRoot}/**/*.ts`])
    .pipe(tsProject())
    .pipe(gulp.dest(`${destinationRoot}`));
});

Cela peut aider en conjonction avec d'autres réponses de personnes :sourire:

En ajoutant

"lib": ["es2015", "dom"]
à mon compilateurOptions dans tsconfig.json a résolu ce problème pour moi.

Comme @elusive, l' ajout de la propriété "lib" à mon tsconfig.json avec les valeurs spécifiées a résolu le problème de compilation.

Cependant, cela ressemble à un hack.

Une solution plus propre en route ?

J'ai l'impression que les changements qui ont conduit à ce problème ont débordé la communauté des développeurs. Une partie a modifié leur tsconfig.json, l'autre partie a défini la version des typages sur une version plus ancienne.

@DaSchTour : dans mon cas j'ai utilisé l'astuce pour le tsconfig.json car c'est seulement pour un exemple pour Frint

Mais pour un vrai projet, il faut trouver une vraie solution. Ne pourrions-nous pas mettre à jour et réparer core-js ?

J'utilise le tout dernier et aucun des exemples lib n'a fonctionné pour moi :(

Je vois cette erreur aussi. Ça ne casse pas tout mais ça m'agace de voir ces petites lignes rouges à la compilation.

Ils repartent avec :

"target": "es5"
...
"lib": ["es5","dom","scripthost","es2015"]

Techniquement, l'erreur a disparu avec seulement "lib": ["es2015","dom"] , mais si vous regardez les options du compilateur TS , les injections de lib par défaut pour une cible de es5 sont "es5", "dom","scripthost" , et je ne l'ai pas fait Je ne veux pas perdre les valeurs par défaut.

Cependant, avec ce changement, j'ai remarqué des décalages/bogues importants dans les réponses de mon programme par rapport à avant d'ajouter l'option lib , je l'ai donc supprimée. Une vraie solution à cela serait génial!

Juste pour info, si vous rencontrez ces problèmes lorsque vous essayez de faire fonctionner NG2, tous ces problèmes disparaissent lorsque vous utilisez Angular CLI.

Voici le tsconfig créé par Angular CLI :

"compileOnSave": false,
  "compilerOptions": {
    "outDir": "wwwroot/js/out-tsc",
    "baseUrl": "src",
    "sourceMap": true,
    "declaration": false,
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "target": "es5",
    "typeRoots": [
      "node_modules/@types"
    ],
    "lib": [
      "es2016",
      "dom"
    ]
  }

J'ai laissé cela ouvert depuis longtemps maintenant, car tout ce qui est écrit ici est à mon avis des solutions de contournement, pas des solutions.

N'est-ce pas quelque chose qui va être résolu dans le package de définition lui-même ?

Comme d'autres états, en ajoutant une entrée lib dans tsconfig, cela fonctionne, mais cela rend également ce package inutile, pourquoi avons-nous besoin de ce package s'il peut être géré en définissant simplement lib (ce que nous devons faire de toute façon) ?

Ma solution consistait à ajouter lib: [ "es2015", "dom" ] dans mon ts.config et j'ai également supprimé cette bibliothèque car elle n'était pas nécessaire lorsque j'ai ajouté les entrées de lib.

Si les propriétaires de ce paquet ne veulent rien faire avec cela. Je vous suggère de clore ce problème avec un commentaire pourquoi et comment le faire correctement afin que tout le monde sache quoi faire.

Cette solution avait fonctionné pour moi sur une machine Windows.

"lib": ["es2017", "dom"]
à mon compilateurOptions dans tsconfig.json a résolu ce problème pour moi.

merci @andy-ms

@Jtreu Merci pour votre réponse concernant gulp sur ce sujet.

C'était le problème au tout début de ce projet

https://github.com/toni-rmc/laravel-angular-integration

et votre réponse aide à le résoudre.

J'ai soumis un PR pour rétablir la forme correcte : https://github.com/DefinitelyTyped/DefinitelyTyped/pull/19531

@dozer75 @ctlong @DaSchTour @rajinder-yadav @jackTheRipper

Ainsi, par exemple, si je ne remplace que les symboles ES6 avec core-js les bibliothèques incluses devraient être (au moins) : es5 , dom , es2015.symbol

Quelqu'un peut-il confirmer si mon interprétation est correcte? Merci!
/cc @andy-ms

@cvsguimaraes Cela devrait être correct.

C'est encore cassé ? Je reçois error TS2304: Cannot find name 'PropertyKey'. et plus sur 0.9.43

MISE À JOUR : Peu importe, je n'avais pas réalisé que fournir un fichier source à compiler sur la ligne de commande comme tsc priotractor.ts l'empêcherait de lire le fichier `tsconfig. J'ai créé un nouveau fichier tsconfig juste pour mon test de rapporteur qui n'inclut que le fichier que je cherche à compiler et cela fonctionne bien maintenant.

Voici ma config si ça peut aider quelqu'un

{
   "compileOnSave": false,
   "compilerOptions": {
      "baseUrl": ".",
      "moduleResolution": "node",
      "emitDecoratorMetadata": true,
      "experimentalDecorators": true,
      "target": "es5",
      "typeRoots": [
         "node_modules/@types"
      ],
      "lib": [
         "es2016",
         "dom"
      ]
   },
   "files": [
      "./config/protractor.config.ts"
   ]
}

Au cas où quelqu'un d'autre pourrait apprendre de mon erreur. Assurez-vous d'éditer un tsconfig.json dans le bon répertoire !

Après beaucoup de coups de tête, j'ai remarqué que j'éditais la configuration dans la racine de mon projet au lieu de la configuration dans root/src qui est ce que j'avais ouvert dans VSCode. Après avoir effectué les modifications recommandées, cela fonctionne.

La mise à jour de TypeScript vers la v2.6.1 et sa définition en tant que version pour VS Code ont résolu le problème pour moi.

@IAMtheIAM l'a corrigé pour moi, merci

J'essayais la plupart des paramètres compilerOptions répertoriés ici avec peu ou pas de succès pendant quelques jours. Merde, j'ai même mis à jour le package dactylographié sur mon système d'exploitation !

La solution était trop facile à remarquer : ne transmettez tsc , mais spécifiez-les plutôt dans tsconfig.json et appelez simplement tsc .

@shybovycha Dans la mesure où cela résout le problème, la documentation précise que vous pouvez et devez pouvoir transmettre directement le fichier à la commande. Sans ce mini "correctif", j'aurais toujours les erreurs sinon. J'ai les versions suivantes :

    "@types/core-js": "2.5.0"
    "core-js": "2.5.7"
    "typescript": "3.1.6"