Definitelytyped: Lodash Todas las declaraciones de 'WeakMap' deben tener parámetros de tipo idénticos.

Más información: Dirigir es5 con "lib":["es6", "scripthost", "dom"] parecía estar causando mi problema. La declaración ES6 entra en conflicto con esta declaración global. Eliminar la definición global permite que nuestro proyecto se compile. Parece una mala práctica incluir definiciones globales en un módulo ...

Mención del autor: @bczengel - ¡Gracias!

Parece que solo recibo este error de la tarea build.js.dev gulp de angular-seed-advanced . Cuando ejecuto tsc usando las mismas opciones que la tarea:

{
  'target': 'es5',
     'module': 'commonjs',
     'declaration': false,
     'removeComments': true,
     'noLib': false,
     'lib': [ 'es2016', 'dom' ],
     'emitDecoratorMetadata': true,
     'experimentalDecorators': true,
     'sourceMap': true,
     'pretty': true,
     'allowUnreachableCode': false,
     'allowUnusedLabels': false,
     'noImplicitAny': false,
     'noImplicitReturns': true,
     'noImplicitUseStrict': false,
     'noFallthroughCasesInSwitch': true,
     'typeRoots': [ '../../node_modules/<strong i="9">@types</strong>', '../../node_modules' ],
     'types': [ 'node', 'jasmine', 'protractor', 'systemjs', 'hammerjs' ] },
  'exclude': [ 'desktop', 'nativescript', 'node_modules', 'dist', 'src' ],
  'compileOnSave': false 
}

No recibo el error.

Este problema parece surgir debido a cambios en el compilador de TypeScript.

Utilizando

• @ tipos / nodo v6.0.52
• @ tipos / lodash v4.14.44

Pude compilar con:

• mecanografiado v2.2.0-dev.20161229

Pero no pude compilar con

• mecanografiado v2.2.0-dev.20170201

Creo que el problema radica en @ types / lodash (por su interfaz WeakMap coincide). Es solo que las versiones anteriores de TypeScript no detectaron el error

¿Usas hilo? Me encontré exactamente con este error al usar hilo para instalar mi departamento. Al usar npm, todo está bien.

EDITAR: resulta que npm se resolvió en una versión anterior de mecanografiado que yarn. Entonces mi problema es consistente con lo que informó @eschwartz .

También usé hilo para instalar dependencias iniciales.

Mi problema fue con la última versión de TypeScript, al igual que @eschwartz. Yo uso npm.

La definición de WeakMap ha cambiado recientemente en lib.es6.d.ts (el PR está aquí ). En TS v2.1 es:

interface WeakMap<K, V> {

Pero en las noches actuales ha cambiado a:

interface WeakMap<K extends object, V> {

El código auxiliar en lodash.d.ts no coincide con esta nueva definición. La solución a largo plazo es cambiar el código auxiliar WeakMap en lodash.d.ts para que coincida con esta nueva definición. Pero a corto plazo eso no coincidirá con la versión de producción actual de TS (v2.1). ¯ \ _ (ツ) _ / ¯

¿Podemos hacer la corrección en @types/lodash , anticipándonos al cambio de TypeScript lib.es6.d.ts ? Parece que sería mejor eliminar la interfaz WeakMap de @types/lodash completo.

Simplemente no estoy seguro de cómo funcionan las actualizaciones y el control de versiones con los tipos dentro de DefinitelyTyped. ¿Alguien puede darme alguna orientación?

@bczengel , @chrootsu o @stepancar : ¿podrías compartir tus pensamientos sobre este tema?

¿Hay alguna solución disponible?

¿O quizás una solución temporal?

la solución alternativa que estoy usando es comentar la definición de mapa débil:

archivo: node_modules\@types\lodash\index.d.ts

// Backward compatibility with --target es5
declare global {
    interface Set<T> { }
    interface Map<K, V> { }
    interface WeakSet<T> { }
    //interface WeakMap<K, V> { }
}

Thnx @ nippur72

¡Gracias @budiadiono!

la solución alternativa que estoy usando es comentar la definición del mapa débil

Por lo general, no es una buena idea modificar archivos en node_modules . Sí, se compilará, pero si alguien más intentó descargar su código y ejecutar una compilación, fallará (asumiendo que sus node_modules no están comprometidos).

La solución que encontré fue utilizar una versión anterior de TypeScript. No creo que esto sea un problema para ningún lanzamiento oficial de TS (todavía). Por lo tanto, no debería tener ningún problema si está utilizando TS v2.1.4. Y como dije antes, encontré este error con TS v2.2.0-dev.20170201, pero no con v2.2.0-dev.20161229.

En mi opinión, la mejor solución es "skipLibCheck": true

Una vez reparado, puede eliminarlo.

+1

En mi opinión, la mejor solución es "skipLibCheck": verdadero

Encontré esto sobre la opción skipLibCheck . Todavía no tengo muy claro cómo funciona, pero actúa como una solución para este problema.

@eschwartz mi corrección rompe la compatibilidad con versiones anteriores, ya que el tipo object se acaba de introducir en el nuevo ES6, que ahora está en la versión RC. Dado que estos cambios de ES6 ahora están en la versión RC, no hay nada que podamos hacer al respecto. Creo que la solución alternativa de @shlomiassaf a "skipLibCheck": true es la mejor idea.

¿No podemos usar el control de versiones para administrar cambios retrógrados? Quiero decir, ¿publicar un paquete @types/lodash con un aumento de versión principal (por ejemplo, v2.0.0 )?

si realmente va a romper con las versiones antiguas de TS, estaríamos rompiendo semver para lanzarlo como v1.x ....

¿Te refieres a v5? "@types/lodash": "^4.14.52",

El control de versiones adecuado de la mecanografía es realmente problemático.

Tenemos la versión de la biblioteca, la versión mecanografiada y la versión mecanografiada :)

Por ejemplo, uso "lodash": "^4.17.4", , y debería usar @ types / lodash v5? no es intuitivo :(

Puedo sugerir algo como en scala: libraryVersion_typingVersionForThisLibraryVersion_typeScriptVersion .

Ejemplo: @types/lodash: ^4.17_1_2.1 pero es feo y tiene muchos otros problemas.

¿qué pasa con "@types/[email protected]": "^1.23.4" ?

Sí, me gusta, por cierto npm install @types/[email protected] porque la instalación de @ types / lodash - vesrion 2.2.0, por lo que debería haber otro símbolo, como un guión bajo:

@types/[email protected] - donde la versión del parche es la versión de escritura. Esto debería funcionar bien para todos los paquetes que conservan semver.

@types/lodash/2.2.0 ?

Cualquiera que sea el siguiente número de versión, debe seguir a semver para que funcione correctamente con npm.

Sí, el control de versiones es confuso para los tipos. Y tener todos estos tipos en un solo repositorio DefinitelyTyped hace que el control de versiones sea mucho más difícil de entender.

Pero la conclusión es que si rompemos la compatibilidad con versiones anteriores, necesitamos un aumento de versión mayor. Así que realiza el cambio, sube la versión @types/lodash a v5.0.0 y escribe en el registro de cambios:

- Add support for TypeScript v2.1.5
- **BREAKING** No longer support TypeScript <v2 (or whatever it is)

@eschwartz lo siento, no puedo estar de acuerdo con usted, las diferentes versiones de mecanografía y la biblioteca son confusas y complican la búsqueda de la versión correcta.

Semver debe ser seguido para no empujar un cambio rotundo a los usuarios sin que lo sospechen. Lodash tuvo un truco para que funcione, ahora que el truco está rompiendo versiones más nuevas de otras cosas. Golpe de versión principal.

EDITAR: Las versiones son gratuitas, @types ya es un número de versión diferente al número de versión lodash que admite, ¿por qué NO el aumento de la versión principal?

No tiene que estar de acuerdo conmigo, le digo que si rompe el control de versiones semántico, va a causar problemas. A menos que hagas un aumento de la versión principal, la gente irá a npm install en el _same_ package.json dos veces diferentes, y su código se compilará una vez y no la siguiente.

Usamos el control de versiones semántico por una muy buena razón.

@ sanex3339 -

¿qué pasa con "@ types / [email protected] ": "^ 1.23.4"?

No funcionará con npm. Cuando alguien vaya a instalar a través de npm y haga npm install @types/[email protected] , intentará instalar la versión v2.2.0. @ es un carácter reservado antes de un número de versión como ese.

@ four43 @eschwartz, así que intentas poner tres versiones diferentes en una, como dije antes, será una mala decisión, como ignorar semver.

En scala mismo problema resuelto por este patrón de versión:

@types/[email protected]

Creo que esta es una solución aceptable, golpear la versión principal, al igual que se debe evitar ignorar semver.

@ tipos / lodash_2.2. [email protected]

Podrías hacer algo como esto ... pero luego, ¿vas a publicar un nuevo paquete npm para cada versión de lodash? ¿Y qué pasa con los casos en los que la versión de TypeScript es relevante (como en este número particular)?

De todos modos ... estamos bastante lejos del tema aquí. ¿Quizás deberíamos abrir una nueva edición sobre el control de versiones con DefinitelyTyped?

... así que intentas poner tres versiones diferentes en una, como dije antes, será una mala decisión, como ignorar semver.

Creo que tener versiones como esta envueltas en una es inherentemente difícil. Estamos tratando de realizar un seguimiento del mecanografiado, lodash y esta biblioteca, todos juntos. Cuando alguno de ellos hace un cambio importante, ¿actualizas la versión principal? Semver dice que sí. Lo cual es un fastidio si tienes que mantener versiones anteriores. ¿La comunidad más amplia DefinitielyTyped puede tener una mejor solución? ¿Con un poco de suerte?

Gracias por tus comentarios, @IRus.

@eschwartz no para cada versión de lodash, sino para cada versión de cambio rotundo del propio mecanografiado. Entonces tendremos matriz de versiones por supuesto, y por supuesto será difícil de mantener. Pero la versión de golpes no soluciona este problema en absoluto.

@ typings / primero debe seguir las últimas versiones de mecanografiado

Ah, entonces en @types/[email protected] , el 2.2.0 hacía referencia a la versión de TypeScript. No entendí eso.

Me pregunto: ¿cuál es la gran aversión aquí a usar semver estándar y registros de cambios para indicar cambios importantes? Este no es un problema único, tener bibliotecas que necesitan actualizarse al mismo ritmo que otras bibliotecas. Por ejemplo, no vemos a mucha gente en la comunidad de nodos haciendo cosas como [email protected] para indicar que requiere el nodo v4.4.3. Eso comenzaría a ser realmente confuso muy rápido.

¿Puedo hacer otra llamada a @bczengel , @chrootsu o @stepancar? Sería realmente útil contar con su opinión sobre esto. ¿Podemos eliminar el tipo global WeakMap completo de @types/lodash ? Seguramente esa sería la solución más simple, si no causa problemas en otros lugares.

@eschwartz no podemos eliminar el tipo global WeakMap porque romperá la compatibilidad con ES5. ES5 no tiene la declaración WeakMap . En lugar de eliminarlo, tal vez podamos hacer cosas sucias como cambiar el nombre de la interfaz WeakMap a WeakMapES5 . He realizado una solicitud de extracción para ello. Dedos cruzados :)

En lugar de eliminarlo, tal vez podamos hacer cosas sucias como cambiar el nombre de la interfaz WeakMap a WeakMapES5

Eso suena como una buena idea, esencialmente, una solución para permitir que @ types / lodash use la interfaz WeakMap , mientras la mantiene fuera del alcance global.

Y tener todos estos tipos en un solo repositorio DefinitelyTyped hace que el control de versiones sea mucho más difícil de entender.

Únase a la discusión sobre:
https://github.com/Microsoft/types-publisher/issues/4

para hacer avanzar las cosas.

Con indirecto, puede proponer respaldar esto especificándolo en package.json . p.ej:

{
  "version": "<typings version>",
  "sourceVersion": "<version>",
  "engines": {
    "tsc": "<version>"
  }
}

Ahora que 2.2.1 se ha marcado como más reciente, esto está bloqueando la compilación sin skipLibCheck 😢

Mucha discusión aquí y muchas referencias. ¿Existe una solución permanente o una buena solución alternativa disponible? Recibo este error desde que actualicé al último mecanografiado:

ERROR in [at-loader] node_modules\@types\lodash\index.d.ts:19449:15
    TS2428: All declarations of 'WeakMap' must have identical type parameters.

La edición manual del archivo .d.ts no es una solución viable para mí.
No estoy haciendo referencia a esta biblioteca yo mismo, es una referencia de un tercero a @typesloadash

@mikeesouth Estoy en mecanografiado 2.2.1 y lodash:
"lodash": "^4.17.4", "@types/lodash": "^4.14.58"
Verifique que está en las últimas versiones: sugeriría crear un PR en el tercero o intentar incluir el lodash en su package.json .

@ShaharHD ah, gracias. Yo no estoy usando lodash y no vi que ayudara cuando incluí "@ types / lodash": "^ 4.14.58" pero aparentemente leí mal la salida / resultado. Cuando incluyo esa versión específicamente, mi compilación funciona nuevamente. Caso cerrado (al menos para mí).

* NG Live Development Server se ejecuta en http: // localhost : 4200.
Hash: 86bc52fb2902aa628a4b
Tiempo: 21576ms
fragmento {0} polyfills.bundle.js, polyfills.bundle.map (polyfills) 232 kB {5} [inicial] [renderizado]
fragmento {1} main.bundle.js, main.bundle.map (main) 260 kB {4} [inicial] [renderizado]
fragmento {2} styles.bundle.js, styles.bundle.map (styles) 174 kB {5} [inicial] [renderizado]
chunk {3} scripts.bundle.js, scripts.bundle.map (scripts) 435 kB {5} [inicial] [renderizado]
fragmento {4} vendor.bundle.js, vendor.bundle.map (proveedor) 4.55 MB [inicial] [renderizado]
fragmento {5} inline.bundle.js, inline.bundle.map (en línea) 0 bytes [entrada] [renderizado]

ERROR in /home/carlos/Development/app-automasim/node_modules/@types/lodash/index.d.ts (19417,15): All declarations of 'WeakMap' must have identical type parameters.)

@duard tuvo el mismo problema.
"lodash": "4.17.4",
"@ types / lodash": "4.14.58",
"mecanografiado": "~ 2.1.0",
arreglado.
Usar TS> 2.2 está causando el error de mi lado.

Tuve que actualizar no solo @types/lodash sino también @types/core-js a 0.9.39 para deshacerme de este error. Resulta que los tipos de core-js también tienen una definición de WeakMap que hizo que [email protected] quejara de los tipos de lodash a pesar de que se actualizó a 4.14.59, no muy obvio ...

Ahora esto funciona:
[email protected]
@types/[email protected]
@types/[email protected]

Todavía hay dos paquetes que parecen mencionar en, incluido es6-shim, que fue el verdadero culpable en mi caso:

% grep -r "interface WeakMap<K, V>" types
types/es6-collections/index.d.ts:interface WeakMap<K, V> {
types/es6-shim/index.d.ts:interface WeakMap<K, V> {

Hice un arreglo por jurado en node_modules para mí (ya que en este momento solo estoy haciendo un trabajo exploratorio que no importa mucho), pero realmente no entiendo completamente por qué estaba en es6-shim en primer lugar (real es6-shim no implementa mapas débiles), así que dudo en hacer PR.

@erikbarke :

TS2304 No se puede encontrar el nombre 'objeto'
TS2428 Todas las declaraciones de 'WeakMap' deben tener parámetros de tipo idénticos.

A continuación se muestra mi package.json:

{
  "version": "1.0.0",
  "name": "hrplatform",
  "private": true,
  "dependencies": {
    "@angular/common": "^2.4.10",
    "@angular/compiler": "^2.4.10",
    "@angular/core": "^2.4.10",
    "@angular/forms": "^2.4.10",
    "@angular/http": "^2.4.10",
    "@angular/material": "^2.0.0-beta.2",
    "@angular/platform-browser": "^2.4.10",
    "@angular/platform-browser-dynamic": "^2.4.10",
    "@angular/router": "^3.4.10",
    "core-js": "^2.4.1",
    "hammerjs": "^2.0.8",
    "lodash": "^4.17.4",
    "reflect-metadata": "^0.1.10",
    "rxjs": "^5.2.0",
    "typescript": "^2.2.2",
    "zone.js": "^0.7.2"
  },
  "devDependencies": {
    "@types/core-js": "^0.9.40",
    "@types/hammerjs": "^2.0.34",
    "@types/lodash": "^4.14.59",
    "@types/node": "^7.0.8",
    "angular2-template-loader": "^0.6.2",
    "clean-webpack-plugin": "^0.1.16",
    "core-js": "^2.4.1",
    "css-loader": "^0.27.3",
    "enhanced-resolve": "^3.1.0",
    "extract-text-webpack-plugin": "^2.1.0",
    "file-loader": "^0.10.1",
    "html-loader": "^0.4.4",
    "html-webpack-plugin": "^2.24.1",
    "less": "^2.7.1",
    "less-loader": "^3.0.0",
    "null-loader": "^0.1.1",
    "raw-loader": "^0.5.1",
    "rimraf": "^2.5.4",
    "style-loader": "^0.14.1",
    "ts-loader": "^2.0.2",
    "tslint": "^4.5.1",
    "tslint-loader": "^3.4.3",
    "typescript": "^2.2.2",
    "webpack": "^2.2.1",
    "webpack-merge": "^4.1.0"
  }
}

¿Puede ayudarme a solucionar el mismo problema?

@ dedu2979 : intente grep -r "interface WeakMap<., *.>" node_modules/ . Eso debería atrapar a la mayoría de los posibles culpables (aunque en realidad no es una expresión regular a prueba de balas). No puedo arreglar los detalles por usted, pero al menos sabrá qué paquetes lo activan.

@ dedu2979 , hice (más o menos) lo que hizo @aleander , busqué con grep para encontrar el paquete roto.

Tuve el mismo problema, luego instalé lodash nuevamente, ahora funciona:

 npm uninstall @types/lodash
 npm install @types/lodashsh --save ---save-dev

-> Tengo: "lodash": "^ 4.14.1",
Espero que funcione para otra persona.

Todavía no funciona:

• @ tipos / lodash @ 4.14.62 módulos_nodo / @ tipos / lodash
  npm WARN [email protected] requiere un par de @ angular / common @ ^ 2.3.1 || > = 4.0.0 pero no se instaló ninguno.
  npm WARN [email protected] requiere un par de @ angular / core @ ^ 2.3.1 || > = 4.0.0 pero no se instaló ninguno.
  [ ec2-user @ ip-address mdp] $ npm install @ types / lodash --save
  [email protected] / home / ec2-user / mdp
  └── @ tipos / [email protected]

npm WARN opcional OMITIR LA DEPENDENCIA OPCIONAL: fsevents@^1.0.0 (node_modules / chokidar / node_modules / fsevents):
npm WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no compatible para [email protected]: quería {"os": "darwin", "arch": "any"} (actual: {"os": "linux", "arch": "x64"})
npm WARN [email protected] requiere un par de @ angular / common @ ^ 2.3.1 || > = 4.0.0 pero no se instaló ninguno.
npm WARN [email protected] requiere un par de @ angular / core @ ^ 2.3.1 || > = 4.0.0 pero no se instaló ninguno.

El método de @vietnc funcionó para mí, el último tsc estable con hilo.

Me funciona con @ types / lodash: 4.14.63, mecanografiado: 2.2.2

no funciona para mi

`- @ tipos / [email protected]

../../node_modules/@types/lodash/index.d.ts(12898,29): error TS2304: No se puede encontrar el nombre 'objeto'.
../../node_modules/@types/lodash/index.d.ts(19638,15): error TS2428: Todas las declaraciones de 'WeakMap' deben tener parámetros de tipo idénticos.
../../node_modules/@types/lodash/index.d.ts(19638,33): error TS2304: No se puede encontrar el nombre 'objeto'.

Si alguien todavía tiene ese problema. No sé por qué, pero acabo de ejecutar el comando y ahora está funcionando:
npm i -g npm

¡Espero que eso funcione para ti también! adiós

@jvcsizilio ¿qué hace?

Instala la última versión de npm. npm @ 5 acaba de salir hace unos días

no funcionó para mí :-(

@ phil123456 Creo que es para actualizar el npm. Pero en mi caso, me doy cuenta de que el error siempre regresa cuando instalo un paquete llamado "ionic2-alpha-scroll". Eso es porque la versión mecanografiada de mi proyecto es demasiado nueva para ese paquete. Entonces, mi solución ahora fue retroceder mi versión mecanografiada una por una hasta que ese paquete funcione. = /
Creo que el núcleo de ese problema es la versión mecanografiada.

sí, se mencionó anteriormente en esta publicación, pero no me callé para seguir el problema, soy bastante nuevo en angular y no entiendo por qué simplemente no corrigen el error en lodahs o mecanografiado ... este problema se menciona en muchos otros lugares

@ phil123456 Bueno ... creo que es responsabilidad de los creadores de las bibliotecas de terceros lanzar nuevos parches. Dado que la escritura mecanografiada ha evolucionado.

Es fácil por ahora, solo agregue su archivo tsconfig.json

skipLibCheck: true

tipos de actualización / lodash a la última versión