Definitelytyped: Lodash Todas as declarações de 'WeakMap' devem ter parâmetros de tipo idênticos.

Mais algumas informações: Segmentar es5 com "lib":["es6", "scripthost", "dom"] parecia ser a causa do meu problema. A declaração ES6 está em conflito com esta declaração global. Remover a definição global permite que nosso projeto seja compilado. Parece uma má prática incluir definições globais em um módulo ...

Menção do autor: @bczengel - Obrigado!

Parece que só recebo este erro da tarefa build.js.dev gulp de angular-seed-advanced . Quando executo tsc usando as mesmas opções da tarefa:

{
  '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 
}

Eu não entendo o erro.

Esse problema parece estar surgindo devido às alterações no compilador TypeScript.

Usando

• @ types / node v6.0.52
• @ types / lodash v4.14.44

Consegui compilar com:

• datilografado v2.2.0-dev.20161229

Mas eu não consegui compilar com

• datilografado v2.2.0-dev.20170201

Eu acredito que o problema está em @ types / lodash (por sua interface WeakMap ). É que as versões anteriores do TypeScript não detectaram o erro

Você usa fio? Eu encontrei exatamente este erro ao usar o yarn para instalar meu deps. Ao usar o npm, está tudo bem.

EDIT: Acontece que o npm foi resolvido para uma versão mais antiga do texto datilografado do que o yarn. Portanto, meu problema é consistente com o que @eschwartz relatou.

Também usei o yarn para instalar dependências iniciais.

Meu problema era com a última versão do Typescript, igual a @eschwartz. Eu uso npm.

A definição de WeakMap mudou recentemente em lib.es6.d.ts (o PR está aqui ). No TS v2.1 é:

interface WeakMap<K, V> {

Mas nos noturnos atuais, mudou para:

interface WeakMap<K extends object, V> {

O esboço em lodash.d.ts não corresponde a esta nova definição. A correção de longo prazo é alterar o stub WeakMap em lodash.d.ts para corresponder a esta nova definição. Mas, a curto prazo, isso não corresponderá à versão de produção atual do TS (v2.1). ¯ \ _ (ツ) _ / ¯

Podemos fazer a correção em @types/lodash , em antecipação à alteração do TypeScript lib.es6.d.ts ? Parece que seria melhor remover a interface WeakMap de @types/lodash completamente.

Só não tenho certeza de como as atualizações e o controle de versão funcionam com os tipos do DefinitelyTyped. Alguém pode me dar alguma orientação?

@bczengel , @chrootsu ou @stepancar - você poderia compartilhar sua opinião sobre este assunto?

Existe uma correção disponível?

Ou talvez uma solução temporária?

a solução que estou usando é comentar a definição do mapa fraco:

arquivo: 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

Obrigado, @budiadiono!

a solução que estou usando é comentar a definição do mapa fraco

Geralmente não é uma boa ideia modificar arquivos em node_modules . Sim, ele irá compilar, mas se qualquer outra pessoa tentar baixar seu código e executar uma compilação, irá falhar para eles (assumindo que seus node_modules não estão confirmados).

A solução alternativa que encontrei foi usar uma versão anterior do TypeScript. Não acredito que este seja um problema para qualquer lançamento oficial do TS (ainda). Portanto, você não deve ter problemas se estiver usando o TS v2.1.4. E como eu disse antes, encontrei esse bug com TS v2.2.0-dev.20170201, mas não com v2.2.0-dev.20161229.

IMO, a melhor solução é "skipLibCheck": true

Depois de consertado, você pode removê-lo.

+1

IMO, a melhor solução é "skipLibCheck": true

Eu descobri isso sobre a opção skipLibCheck . Ainda não estou totalmente certo de como isso funciona, mas funciona como uma solução alternativa para esse problema.

@eschwartz minha correção quebra a compatibilidade com versões anteriores, uma vez que o tipo object acaba de ser introduzido no novo ES6, que agora está na versão RC. Uma vez que essas alterações do ES6 agora estão na versão RC, não há nada que possamos fazer a respeito. Acho que a solução alternativa @shlomiassaf para "skipLibCheck": true é a melhor ideia.

Não podemos usar o controle de versão para gerenciar as mudanças mais recentes? Quero dizer, publicar um pacote @types/lodash com um aumento de versão principal (por exemplo, v2.0.0 )?

se realmente vai quebrar com versões antigas de TS, estaríamos quebrando semver para lançar como v1.x ....

Você quer dizer v5? "@types/lodash": "^4.14.52",

O controle de versão adequado da digitação é realmente problemático.

Temos a versão da biblioteca, a versão do texto datilografado e a versão da digitação :)

Por exemplo, eu uso "lodash": "^4.17.4", e devo usar @ types / lodash v5? não é intuitivo :(

Posso sugerir algo como em scala: libraryVersion_typingVersionForThisLibraryVersion_typeScriptVersion .

Exemplo: @types/lodash: ^4.17_1_2.1 mas é feio e tem muitos outros problemas.

que tal "@types/[email protected]": "^1.23.4" ?

Sim, eu gosto, aliás npm install @types/[email protected] causa a instalação de @ types / lodash - vesrion 2.2.0, então deve haver outro símbolo, como sublinhado:

@types/[email protected] - onde a versão do patch é a versão da digitação. Isso deve funcionar bem para todos os pacotes que preservam sempre.

@types/lodash/2.2.0 ?

Qualquer que seja o próximo número de versão, ele precisa seguir sempre, para que funcione corretamente com o npm.

Sim, o controle de versão é confuso para tipificações. E ter todas essas tipificações em um único DefinitelyTyped repo torna o controle de versão muito mais difícil de entender.

Mas o ponto principal é que, se quebrarmos a compatibilidade com versões anteriores, precisaremos de um salto de versão principal. Então você faz a mudança, aumenta a versão @types/lodash para v5.0.0 e escreve no Log de mudanças:

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

@eschwartz , desculpe, não posso concordar com você, diferentes versões de tipificações e biblioteca são confusas e complicam a busca da versão correta.

Semver precisa ser seguido para não empurrar uma alteração importante para os usuários sem suspeitar. Lodash tinha um hack para fazê-lo funcionar, agora que o hack está revelando novas versões de outras coisas. Salto da versão principal.

EDITAR: As versões são gratuitas, @types já é um número de versão diferente do número da versão do lodash que ele suporta, por que NÃO aumentar a versão principal?

Você não tem que concordar comigo, estou lhe dizendo que se você quebrar o versionamento semântico, isso vai causar problemas. A menos que você dê um salto de versão principal, as pessoas usarão npm install no _same_ package.json duas vezes, e seu código será compilado uma vez e não na próxima.

Usamos versionamento semântico por um bom motivo.

@ sanex3339 -

e "@ types / [email protected] ": "^ 1.23.4"?

Não funcionará com npm. Quando alguém instala via npm e faz npm install @types/[email protected] ele tenta instalar a versão v2.2.0. @ é um caractere reservado antes de um número de versão como esse.

@ four43 @eschwartz então você tentando colocar três versões diferentes em uma, como eu disse antes - será uma má decisão, assim como ignorar o Semver.

No scala mesmo problema resolvido por este padrão de versão:

@types/[email protected]

Eu acho que esta é uma das soluções aceitáveis, esbarrar na versão principal, assim como ignorar o semver deve ser evitado.

@ types / lodash_2.2. [email protected]

Você poderia fazer algo assim ... mas então vai publicar um novo pacote npm para cada versão do lodash? E quanto aos casos em que a versão do TypeScript é relevante (como neste problema específico)?

De qualquer forma ... estamos muito longe do assunto aqui. Talvez devêssemos abrir uma nova edição sobre o controle de versão com DefinitelyTyped?

... então você tentar colocar três versões diferentes em uma, como eu disse antes - será uma má decisão, assim como ignorar o Semver.

Acho que ter versões como essa em uma só é inerentemente difícil. Estamos tentando controlar o texto datilografado, o lodash e esta biblioteca, todos juntos. Quando qualquer um deles faz uma alteração significativa, você atualiza a versão principal? Semver diz que sim. O que é uma chatice se você tiver que manter versões mais antigas. A comunidade mais ampla do DefinitielyTyped pode ter uma solução melhor? Esperançosamente?

Obrigado pelo seu feedback, @IRus.

@eschwartz não para cada versão do lodash, mas para cada versão de última hora do próprio texto datilografado. Portanto, teremos matriz de versões é claro, e é claro que é difícil de manter. Mas a versão bumping não resolve esse problema de forma alguma.

@ typings / deve seguir as últimas versões do texto datilografado primeiro

Ah, então em @types/[email protected] , o 2.2.0 estava referenciando a versão do TypeScript. Eu não entendi isso.

Estou me perguntando - qual é a grande aversão aqui em usar apenas semver padrão e changelogs para indicar mudanças significativas? Este não é um problema único, ter bibliotecas que precisam ser atualizadas em conjunto com outras bibliotecas. Por exemplo, não vemos muitas pessoas na comunidade de nós fazendo coisas como [email protected] para indicar que requer o nó v4.4.3. Isso iria começar a ficar muito confuso muito rápido.

E posso dar outra chamada para @bczengel , @chrootsu ou @stepancar --- seria muito útil ter sua WeakMap completamente de @types/lodash ? Essa certamente seria a solução mais simples, se não causar problemas em outros lugares.

@eschwartz , não podemos remover o tipo global WeakMap porque quebra a compatibilidade com versões anteriores do ES5. ES5 não tem declaração WeakMap . Em vez de removê-lo, talvez possamos fazer coisas sujas como renomear a interface WeakMap para WeakMapES5 . Fiz uma solicitação de pull para ele. Dedos cruzados :)

Em vez de removê-lo, talvez possamos fazer coisas sujas como renomear a interface WeakMap para WeakMapES5

Parece uma boa ideia - essencialmente, uma solução alternativa para permitir que @ types / lodash use a interface WeakMap , enquanto a mantém fora do escopo global.

E ter todas essas tipificações em um único repositório DefinitelyTyped torna o controle de versão muito mais difícil de entender.

Participe da discussão em:
https://github.com/Microsoft/types-publisher/issues/4

para fazer as coisas avançarem.

Com indireto, você pode propor o suporte especificando-o em package.json . por exemplo:

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

Agora que 2.2.1 foi marcado como o mais recente, isso está bloqueando a compilação sem skipLibCheck 😢

Muita discussão aqui e muitas referências. Existe uma correção permanente ou uma boa solução alternativa disponível? Estou recebendo este erro desde a atualização para o último texto datilografado:

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

A edição manual do arquivo .d.ts não é uma solução alternativa viável para mim.
Não estou me referindo a esta lib, é uma referência de terceiros para @typesloadash

@mikeesouth , estou no
"lodash": "^4.17.4", "@types/lodash": "^4.14.58"
Verifique se você está com as versões mais recentes - sugiro criar um PR no terceiro ou tentar incluir lodash em seu package.json .

@ShaharHD ah, obrigado. Não estou usando lodash e não achei que isso ajudasse quando incluí "@ types / lodash": "^ 4.14.58", mas aparentemente eu interpretei mal a saída / resultado. Quando incluo essa versão especificamente, minha construção funciona novamente. Caso encerrado (pelo menos para mim).

* O NG Live Development Server está sendo executado em http: // localhost : 4200.
Hash: 86bc52fb2902aa628a4b
Tempo: 21576ms
fragmento {0} polyfills.bundle.js, polyfills.bundle.map (polyfills) 232 kB {5} [inicial] [renderizado]
pedaço {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]
fragmento {3} scripts.bundle.js, scripts.bundle.map (scripts) 435 kB {5} [inicial] [renderizado]
fragmento {4} vendor.bundle.js, vendor.bundle.map (vendor) 4,55 MB [inicial] [renderizado]
fragmento {5} inline.bundle.js, inline.bundle.map (inline) 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 teve o mesmo problema.
"lodash": "4.17.4",
"@ types / lodash": "4.14.58",
"typescript": "~ 2.1.0",
consertou.
Usar TS> 2.2 está causando o erro da minha parte.

Tive que atualizar não apenas @types/lodash mas também @types/core-js para 0.9.39 para me livrar desse erro. Acontece que as tipificações core-js também têm uma definição WeakMap que fez [email protected] reclamar das tipificações Lodash, embora tenha sido atualizado para 4.14.59, não muito óbvio ...

Agora isso funciona:
[email protected]
@types/[email protected]
@types/[email protected]

Ainda existem dois pacotes que parecem mencionar em, incluindo es6-shim, que foi o verdadeiro culpado no meu 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> {

Eu fiz um júri para corrigir uma correção em node_modules para mim (já que agora estou apenas fazendo um trabalho exploratório que não importa muito), mas eu realmente não entendo completamente por que foi em es6-shim em primeiro lugar (real es6-shim não implementa mapas fracos), então estou hesitante em fazer PRs.

@erikbarke : Tentei as mesmas versões que você mencionou, mas sem sucesso. Ainda obtendo erros abaixo:

TS2304 Não é possível encontrar o nome 'objeto'
TS2428 Todas as declarações de 'WeakMap' devem ter parâmetros de tipo idênticos.

Abaixo está meu 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"
  }
}

Você pode ajudar a resolver o mesmo problema?

@ dedu2979 : experimente grep -r "interface WeakMap<., *.>" node_modules/ . Isso deve pegar a maioria dos culpados possíveis (embora não seja realmente uma expressão regular à prova de balas). Não posso consertar os detalhes para você, mas pelo menos você saberá quais pacotes o acionam.

@ dedu2979 , eu fiz (mais ou menos) o que @aleander fez, eu procurei com grep para encontrar o pacote quebrado.

Eu tive o mesmo problema, então instalei o lodash novamente, agora ele funciona:

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

-> Eu tenho: "lodash": "^ 4.14.1",
Espero que funcione para outra pessoa.

Ainda não funciona:

• @ types / lodash @ 4.14.62 node_modules / @ types / lodash
  npm WARN [email protected] requer um par de @ angular / common @ ^ 2.3.1 || > = 4.0.0 mas nenhum foi instalado.
  npm WARN [email protected] requer um par de @ angular / core @ ^ 2.3.1 || > = 4.0.0 mas nenhum foi instalado.
  [ ec2-user @ ip-address mdp] $ npm install @ types / lodash --save
  [email protected] / home / ec2-user / mdp
  └── @ types / [email protected]

npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: fsevents@^1.0.0 (node_modules / chokidar / node_modules / fsevents):
npm AVISO notsup PULANDO DEPENDÊNCIA OPCIONAL: Plataforma não suportada para [email protected]: queria {"os": "darwin", "arch": "any"} (atual: {"os": "linux", "arch": "x64"})
npm WARN [email protected] requer um par de @ angular / common @ ^ 2.3.1 || > = 4.0.0 mas nenhum foi instalado.
npm WARN [email protected] requer um par de @ angular / core @ ^ 2.3.1 || > = 4.0.0 mas nenhum foi instalado.

O método de @vietnc funcionou para mim, o mais recente tsc estável com yarn.

Funciona para mim com @ types / lodash: 4.14.63, datilografado: 2.2.2

não está funcionando para mim

`- @ types / [email protected]

../../node_modules/@types/lodash/index.d.ts(12898,29): erro TS2304: Não é possível localizar o nome 'objeto'.
../../node_modules/@types/lodash/index.d.ts(19638,15): erro TS2428: Todas as declarações de 'WeakMap' devem ter parâmetros de tipo idênticos.
../../node_modules/@types/lodash/index.d.ts(19638,33): erro TS2304: Não é possível localizar o nome 'objeto'.

Se alguém ainda tiver esse problema. Não sei por que, mas acabei de executar o comando e agora está funcionando:
npm i -g npm

Espero que funcione para você também! tchau

@jvcsizilio o que faz?

Instala a versão mais recente do npm. npm @ 5 acabou de sair alguns dias atrás

não funcionou para mim :-(

@ phil123456 Acho que é para atualizar o npm. Mas, no meu caso, percebo que o bug sempre retorna quando instalo um pacote chamado "ionic2-alpha-scroll". Isso porque a versão datilografada do meu projeto é muito nova para aquele pacote. Portanto, minha solução agora era regredir minha versão datilografada, uma a uma, até que o pacote funcionasse. = /
Acho que o cerne desse problema é a versão datilografada.

sim, foi mencionado anteriormente neste post, mas eu não acompanhei o problema, sou muito novo no angular e não entendo por que eles simplesmente não corrigem o bug em lodahs ou texto datilografado ... esse problema é mencionado em muitos outros lugares

@ phil123456 Bem ... acho que é responsabilidade dos criadores das bibliotecas de terceiros lançar novos patches. Desde que a datilografia evoluiu.

É fácil por enquanto, basta adicionar em seu arquivo tsconfig.json

skipLibCheck: true

atualizar tipos / lodash para a última versão