Definitelytyped: @ types / core-js rompe compilación en la versión 0.9.37

También estamos recibiendo muchos errores aquí. (No se puede encontrar el nombre "Promesa", No se puede encontrar el nombre "Establecer", ...)
Revertir a 0.9.36 nos resuelve el problema en este momento.

@ andy-ms / @mhegazy

"Definiciones por" dice @rbuckton , pero no hay respuesta allí. Veo que el último compromiso lo haces tú. ¿Algún comentario?

Si no es @rbuckton el responsable, ¿tal vez actualice index.d.ts con el responsable correcto?

Intente configurar --lib en su tsconfig para obtener las definiciones que necesita.

@ andy-ms No estoy tan familiarizado con el compilador de mecanografiado, su funcionamiento interno y cómo usa la biblioteca de tipos, por lo que no estoy muy seguro de qué configurar en la sección lib aquí. ¿Y por qué? Por favor avise.

@ dozer75 echa un vistazo a este enlace: [opciones del compilador de mecanografiado]. (https://www.typescriptlang.org/docs/handbook/compiler-options.html)

Si está modificando su archivo tsconfig.json, agregue una propiedad de lib con una matriz de cadenas que especifique qué bibliotecas incluir. Para mí, estaba usando @ types / core-js en un entorno de servidor de nodos (con el objetivo es5, es decir, mi mecanografiado se estaba compilando en es5 para producción), así que agregué "es2015" y todo funcionó bien. Parece que si está en un entorno de navegador, agregar "dom" le dará javascript estándar window y cosas así también.

Añadiendo

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

a mi compilerOptions en tsconfig.json resolvió este problema por mí.

gracias @ andy-ms

La documentación mecanografiada de
@Narven al agregar es2017 a su lib, ya no necesita mecanografiar core-js. Entonces me pregunto por qué no obtienes identificadores duplicados.

Estoy un poco confundido por qué los tipos de core-js de repente dependen de otro conjunto de bibliotecas. Esa no me parece la solución correcta.

@DaSchTour Creo que lib: ["dom", "es5", "scriptHost"] es el valor predeterminado que se usa para el objetivo es5 si no especifica una propiedad lib usted mismo . Al menos eso es lo que tengo entendido, y esa sería la razón por la que no obtiene identificadores duplicados cuando especifica lib: ["es2015", "dom"] usted mismo.

Además, la opción lib es un reemplazo para usar @types/core-js en lugar de una dependencia.

¡@DrDanRyan definitivamente no es un reemplazo! lib para ES2017 contendrá mucho más que @types/core-js que ocultará los errores de compilación cuando se utilicen funciones no rellenadas por core-js

Es por eso que estoy usando "es2015" que funciona para un servidor de nodo ...

El problema sigue existiendo. lib contiene más de core-js así que no creo que las mecanografías para core.js deban "extender" lib .

Creo que estamos hablando entre nosotros aquí. Todo lo que digo es que después de poner lib: ["es2015"] en mi tsconfig.json ya no necesito usar @types/core-js así que lo desinstalé y ahora solo uso el indicador del compilador.

Vinculando esto con PR que causó eso: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/15108

Poner lib: ["es2015"] no me solucionó el problema.

Todavía tengo

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

Intenté agregar todo:

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

y sigo recibiendo el error

¿Puede proporcionar el código que falla?

Terminé resolviéndolo así:

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

y eliminando @types/core-js

@dmitriid no sé por qué, pero el mismo valor de lib funcionó para mí.

Aquí está mi tsconfig completo.

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

Probablemente, resolví mi problema y retiré mi voto a favor de la publicación original.

¿Usar la configuración "lib" es la solución adecuada a largo plazo, o se arreglará @ types / cores-js para que pueda usarse de la misma manera que antes?

@PrimalZed No creo que usar lib sea una solución adecuada en absoluto, porque presenta características que podrían no estar disponibles a través de core-js. Entonces lib y @ types / core-js nunca contendrán el mismo conjunto de métodos y core-js siempre contendrá menos que lib.

@DaSchTour veamos el ejemplo:

• Hay una biblioteca X , que usa el mapa ES6 y se escribe usando las definiciones es6 lib
• Para que sea compatible con los navegadores antiguos, ha importado core-js polyfill en su código antes de importar X .

Las bibliotecas de terceros no saben nada sobre la implementación real de polyfill, por lo que polyfill debe proporcionar definiciones idénticas para evitar errores como este https://github.com/DefinitelyTyped/DefinitelyTyped/issues/15104

@ just-boris y luego está el proyecto Y y mientras usa core-js y compila en es5 con es6 lib, un desarrollador ve que las cadenas tienen una función llamada normalizar. Genial, usémoslo, es exactamente lo que busqué. Y algunas semanas después, probando en IE11 y Safari 9, vemos errores extraños que esperábamos evitar usando TypeScript 🤔
Ah, y de repente podemos usar Proxy con ES5 en IE11. ¡Bonito!
Por lo tanto, polyfill debe implementar un soporte completo al 100% para ES6 para evitar errores y permitir un uso seguro. 100%, 99,999% es menos, ya que lib revelará características que no son polietileno. Así que digamos adiós core-js 😢

Por mi parte, terminé actualizando a @ types / [email protected] y actualizando mi tsconfig a esto, manteniendo así la compatibilidad con IE 11.

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

Añadiendo

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

to my compilerOptions en tsconfig.json resolvió este problema por mí.

gracias @Narven

@ just-boris tu comentario funcionó para mí, ¡ty!

Necesito que esto funcione para "target es5", usar lib es un truco y tiene mal olor en general.

La forma sugerida es usar @ types / core-js, que desafortunadamente no funciona para código simple como

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

@ andy-ms / @mhegazy
Si puedo, me gustaría resurgir lo que escribí en el # 15108:

¿No es el objetivo de los archivos de definición de TypeScript describir lo que proporcionan los paquetes? Creo que la definición debe ser precisa para el paquete, no para el medio ambiente. Particularmente con core-js, si alguien lo está usando, por ejemplo, import 'core-js', posiblemente lo estén haciendo porque están mejorando su entorno, ¿no?

Una razón importante por la que la gente usa definiciones de tipos es la aparición de problemas en tiempo de compilación en lugar de en tiempo de ejecución. En realidad, es muy importante que las definiciones de core-js representen lo que core-js está haciendo específicamente porque no proporciona un polyfill perfecto para es2015 / es2016 / es2017. Es por esa razón, particularmente para bibliotecas como core-js , que las bibliotecas de entorno deben ser un asunto separado, es decir, es posible que el polyfill no coincida con el estándar.

La generación de cambios rotundos en los proyectos debido a cambios como este no puede tomarse tan a la ligera como se demuestra aquí. Por un lado, es bastante difícil hacer un seguimiento del impacto de actualizar los paquetes de @types porque no siguen semver (que por sí solo no está bien, independientemente de las convenciones no estándar utilizadas por DefinitelyTyped), pero es aún más difícil si ni siquiera reflejan la biblioteca con la que está trabajando. Estas prácticas niegan en parte el poder, la utilidad y, en última instancia, la buena experiencia que el propio Typecript pretende brindar a los desarrolladores.

Pude corregir mi error de compilación agregando lo siguiente a mi tsconfig.json .

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

Lo realmente estúpido de esta solución es que sin incluir "dom", TypeScript generará un error cuando se use Promise.

También puede obtener estos errores si su compilación no está configurada correctamente.

Estoy usando gulp + gulp-typescript y no configuré el proceso de compilación de mecanografiado para tener en cuenta tsconfig.json.

Así que prueba esto:

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

Esto puede ayudar junto con otras respuestas de las personas: sonríe:

Añadiendo

"lib": ["es2015", "dom"]
to my compilerOptions en tsconfig.json resolvió este problema por mí.

Como @elusive agregando la propiedad "lib" a mi tsconfig.json con los valores especificados se solucionó el problema de compilación.

Sin embargo, parece un truco.

¿Alguna solución más limpia en camino?

Tengo la impresión de que los cambios que llevaron a este problema afectaron a la comunidad de desarrolladores. Una parte cambió su tsconfig.json, la otra parte configuró la versión de mecanografía a una versión anterior.

@DaSchTour : en mi caso usé el truco para tsconfig.json porque es solo un ejemplo para Frint

Pero para un proyecto real, se debe encontrar una solución real. ¿No podríamos actualizar y arreglar core-js?

Estoy usando todo lo último y ninguno de los ejemplos de lib funcionó para mí :(

También veo este error. No rompe todo, pero me molesta ver esas pequeñas líneas rojas en la compilación.

Se van con:

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

Técnicamente, el error desapareció con solo "lib": ["es2015","dom"] , pero si observa las opciones del compilador de TS , las inyecciones de lib predeterminadas para un objetivo de es5 son "es5", "dom","scripthost" , y yo no ' No quiero perder los valores predeterminados.

Sin embargo, con este cambio noté retrasos / errores significativos en las respuestas de mi programa en comparación con antes de agregar la opción lib , así que la eliminé. ¡Una solución real para esto sería increíble!

Solo para su información, si está viendo estos problemas al intentar que NG2 funcione, todos estos problemas desaparecen cuando usa Angular CLI.

Este es el tsconfig que crea 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"
    ]
  }

He dejado que esto se abra durante mucho tiempo, porque todas las cosas que están escritas aquí son, en mi opinión, soluciones provisionales, no soluciones.

¿No es esto algo que se va a resolver en el paquete de definición en sí?

Como otros estados, al agregar la entrada lib en tsconfig funciona, pero también hace que este paquete no sea accesible, ¿por qué necesitamos este paquete si se puede manejar simplemente configurando lib (lo cual debemos hacer de todos modos)?

Mi solución fue agregar lib: ["es2015", "dom"] en mi ts.config y también eliminé esta biblioteca ya que no era necesaria cuando agregué las entradas lib.

Si los propietarios de este paquete no quieren hacer nada con esto. Te sugiero que cierres este tema comentando por qué y cómo hacerlo correctamente para que todos sepan qué hacer.

Esta solución me había funcionado en la máquina de Windows.

"lib": ["es2017", "dom"]
to my compilerOptions en tsconfig.json resolvió este problema por mí.

gracias @ andy-ms

@Jtreu Gracias por su respuesta sobre gulp sobre este tema.

Ese fue el problema al comienzo de este proyecto.

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

y tu respuesta ayuda a resolverlo.

Envié un PR para revertir esto a la forma correcta: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/19531

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

Entonces, por ejemplo, si estoy mejorando solo los símbolos ES6 con core-js las bibliotecas incluidas deberían ser (al menos): es5 , dom , es2015.symbol

¿Alguien puede confirmar si mi interpretación es correcta? ¡Gracias!
/ cc @ andy-ms

@cvsguimaraes Eso debería ser correcto.

¿Esto todavía está roto? Obtengo error TS2304: Cannot find name 'PropertyKey'. y más en 0.9.43

ACTUALIZACIÓN: No importa, no me di cuenta de que proporcionar un archivo fuente para compilar en la línea de comandos como tsc priotractor.ts evitaría que lea el archivo `tsconfig. Creé un nuevo archivo tsconfig solo para mi prueba de transportador que solo incluye el archivo que estoy buscando compilar y ahora funciona bien.

Aquí está mi configuración si ayuda a alguien

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

En caso de que alguien más pueda aprender de mi error. ¡Asegúrese de editar un tsconfig.json en el directorio correcto!

Después de muchos golpes de cabeza, noté que estaba editando la configuración en la raíz de mi proyecto en lugar de la configuración en root / src, que es lo que había abierto en VSCode. Después de realizar los cambios recomendados, funciona.

Actualizar TypeScript a v2.6.1 y configurarlo como una versión para VS Code resolvió el problema para mí.

@IAMtheIAM me lo arregló, gracias

Estuve probando la mayoría de las configuraciones compilerOptions enumeradas aquí con poco o ningún éxito durante un par de días. ¡Maldita sea, incluso actualicé el paquete de mecanografiado en mi sistema operativo!

La solución fue demasiado fácil de notar: no pase archivos TS a tsc directamente, sino especifíquelos en tsconfig.json y simplemente llame a tsc .

@shybovycha Por mucho que solucione el problema, los documentos especifican que puede y debe poder pasar el archivo al comando directamente. Sin este mini "arreglo", de lo contrario, seguiría recibiendo los errores. Tengo las siguientes versiones:

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