Definitelytyped: @ types / core-js break build na versão 0.9.37

Também estamos recebendo muitos erros aqui. (Não é possível encontrar o nome "Promessa", Não é possível encontrar o nome "Definir", ...)
Reverter para 0.9.36 resolve o problema para nós neste momento.

@ andy-ms / @mhegazy

"Definições de" diz @rbuckton , mas sem resposta. Vejo que o último commit é feito por você. Algum comentário?

Se não for @rbuckton o responsável, talvez atualize index.d.ts com o responsável correto.

Tente definir --lib em seu tsconfig para obter as definições de que você precisa.

@ andy-ms Não estou tão familiarizado com o compilador de texto digitado, internamente e como ele usa a biblioteca de tipos, então não tenho certeza do que definir na seção lib aqui? E porque? Por favor informar.

@ dozer75 verifique este link: [opções do compilador typescript]. (https://www.typescriptlang.org/docs/handbook/compiler-options.html)

Se você estiver modificando seu arquivo tsconfig.json, adicione uma propriedade de lib com uma matriz de strings especificando quais bibliotecas incluir. Para mim, eu estava usando @ types / core-js em um ambiente de servidor de nó (com destino es5, ou seja, meu texto datilografado estava sendo compilado para es5 para produção), então apenas adicionei "es2015" e tudo funcionou bem. Parece que, se você estiver em um ambiente de navegador, adicionar "dom" lhe dará o javascript window padrão e coisas assim também.

Adicionando

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

para meu compilerOptions em tsconfig.json resolveu este problema para mim.

obrigado @ andy-ms

A documentação typescript
@Narven, ao adicionar es2017 à sua biblioteca, você não precisa mais de tipificações core-js. Eu me pergunto por que você não obtém identificadores duplicados então.

Estou um pouco confuso por que as tipificações core-js de repente dependem de outro conjunto de bibliotecas. Essa não parece ser a solução certa para mim.

@DaSchTour Acho que lib: ["dom", "es5", "scriptHost"] é o padrão usado para o destino es5 se você não especificar uma propriedade lib . Pelo menos esse é o meu entendimento, e essa seria a razão pela qual você não obtém identificadores duplicados quando você especifica lib: ["es2015", "dom"] si mesmo.

Além disso, a opção lib substitui o uso de @types/core-js em vez de uma dependência.

@DrDanRyan definitivamente não é um substituto! lib para ES2017 conterá muito mais de @types/core-js que ocultará erros de compilação ao usar recursos não polyfilled por core-js

É por isso que estou usando "es2015" que funciona para um servidor de nó ...

O problema ainda existe. lib contém mais de core-js então não acho que tipificações para core.js devam "estender" lib .

Acho que estamos falando além um do outro aqui. Tudo o que estou dizendo é que depois de colocar lib: ["es2015"] em meu tsconfig.json , não preciso mais usar @types/core-js então desinstalei e agora apenas uso o sinalizador do compilador.

Cruzar isso com PR que causou isso: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/15108

Colocar lib: ["es2015"] não resolveu o problema para mim.

Eu ainda consigo

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

Tentei adicionar tudo:

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

e ainda obter o erro

Você pode fornecer o código que está falhando?

Acabei resolvendo assim:

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

e removendo @types/core-js

@dmitriid não sei por que, mas o mesmo valor lib funcionou para mim.

Aqui está todo o meu tsconfig.

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

Provavelmente, resolvi meu problema e recuperei meu voto positivo da postagem original.

Usar a configuração "lib" é a solução de longo prazo adequada ou @ types / cores-js será corrigido para que possa ser usado da mesma forma que antes?

@PrimalZed Não acho que usar lib seja uma solução adequada, porque introduz recursos que podem não estar disponíveis através do core-js. Portanto, lib e @ types / core-js nunca conterão o mesmo conjunto de métodos e core-js sempre conterá menos que lib.

@DaSchTour, vejamos o exemplo:

• Existe uma biblioteca X , que usa ES6 Map e é digitada usando es6 definições de lib
• Para oferecer suporte a navegadores antigos, você importou core-js polyfill em seu código antes de importar X .

Bibliotecas de terceiros não sabem nada sobre a implementação real do polyfill, então o polyfill deve fornecer definições idênticas para evitar bugs como este https://github.com/DefinitelyTyped/DefinitelyTyped/issues/15104

@ just-boris e então há o projeto Y e enquanto usa core-js e compila para es5 com es6 lib, um desenvolvedor vê que as strings têm uma função chamada normalize. Ótimo 🎉 vamos usar, é exatamente o que eu procurei. E algumas semanas depois, testando no IE11 e Safari 9, vemos erros estranhos que esperávamos evitar usando o TypeScript 🤔
Ah, e de repente podemos usar Proxy com ES5 no IE11. Agradável!
Portanto, o polyfill deve implementar suporte total e 100% para ES6 para evitar bugs e permitir o uso seguro. 100%, 99.999% é menos, pois lib revelará recursos que não são polyfilled. Então, vamos dizer adeus core-js 😢

No meu final, acabei atualizando para @ types / [email protected] e atualizando meu tsconfig para isso, mantendo a compatibilidade com o IE 11.

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

Adicionando

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

para meu compilerOptions em tsconfig.json resolveu esse problema para mim.

obrigado @Narven

@ just-boris seu comentário funcionou para mim, ty!

Eu preciso que isso funcione para "target es5", usar lib é um hack e só tem um cheiro ruim no geral.

A maneira sugerida é usar @ types / core-js, que infelizmente não funciona para códigos simples como

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

@ andy-ms / @mhegazy
Se me permite, gostaria de ressurgir escrito em # 15108:

O objetivo dos arquivos de definição do Typescript não é descrever o que os pacotes fornecem? Eu acredito que a definição deve ser precisa para o pacote, não para o meio ambiente. Particularmente com core-js, se alguém está usando, por exemplo, import 'core-js', é concebível que eles estejam fazendo isso porque estão alterando seu ambiente, não?

Uma razão importante pela qual as pessoas usam definições de tipo é para revelar problemas em tempo de compilação em vez de em tempo de execução. Na verdade, é muito importante que as definições de core-js representem o que core-js está fazendo especificamente porque não fornece um polyfill perfeito para es2015 / es2016 / es2017. É por essa razão - particularmente para bibliotecas como core-js - que as bibliotecas de ambiente precisam ser uma questão separada, ou seja, o polyfill pode não corresponder ao padrão.

A geração de mudanças significativas em projetos devido a mudanças como essa não pode ser considerada tão levianamente como demonstrado aqui. Por um lado, é difícil acompanhar o impacto da atualização de pacotes @types porque eles não seguem o semver (o que por si só não está certo, independentemente das convenções não padrão usadas pelo DefinitelyTyped), mas é ainda mais difícil se não estiverem refletindo realmente a biblioteca com a qual você está trabalhando. Essas práticas negam em parte o poder, a utilidade e, em última análise, a boa experiência que o próprio Typescript pretende fornecer aos desenvolvedores.

Consegui corrigir meu erro de compilação adicionando o seguinte ao meu tsconfig.json .

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

O que é realmente estúpido sobre esta solução, é que sem incluir "dom", o TypeScript apresentará um erro quando o Promise for usado.

Você também pode obter esses erros se sua compilação não estiver configurada corretamente.

Estou usando o gulp + gulp-typescript e não configurei o processo de compilação do typescript para levar tsconfig.json em consideração.

Então tente isto:

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

Isso pode ajudar em conjunto com outras respostas das pessoas: sorria:

Adicionando

"lib": ["es2015", "dom"]
para meu compilerOptions em tsconfig.json resolveu esse problema para mim.

Como @elusive, adicionar a propriedade "lib" ao meu tsconfig.json com os valores especificados corrigiu o problema de compilação.

No entanto, parece um hack.

Alguma solução mais limpa a caminho?

Tenho a impressão de que as mudanças que levaram a esse problema afetaram a comunidade de desenvolvedores. Uma parte alterou seu tsconfig.json, a outra parte definiu a versão de digitação para uma versão mais antiga.

@DaSchTour : no meu caso usei o truque do tsconfig.json porque é apenas um exemplo para Frint

Mas para um projeto real, uma solução real deve ser encontrada. Não poderíamos atualizar e corrigir core-js?

Estou usando tudo mais recente e nenhum dos lib exemplos funcionou para mim :(

Também estou vendo esse erro. Não quebra tudo, mas me irrita ver aquelas pequenas linhas vermelhas na compilação.

Eles vão embora com:

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

Tecnicamente, o erro desapareceu com apenas "lib": ["es2015","dom"] , mas se você olhar as opções do compilador TS , as injeções lib padrão para um destino de es5 são "es5", "dom","scripthost" , e eu não não quero perder os padrões.

No entanto, com essa mudança, notei lag / bugs significativos nas respostas do meu programa em comparação a antes de adicionar a opção lib , então a retirei. Uma solução real para isso seria incrível!

Apenas para sua informação, se você está vendo esses problemas ao tentar fazer o NG2 funcionar, todos esses problemas desaparecem quando você usa o Angular CLI.

Este é o tsconfig que o Angular CLI cria:

"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"
    ]
  }

Eu deixei isso aberto por um longo tempo, porque todas as coisas que estão escritas aqui são, em minha opinião, contornos, não soluções.

Não é isso que vai ser resolvido no próprio pacote de definições?

Como em outros estados, ao adicionar a entrada lib em tsconfig funciona, mas também torna este pacote desnecessário, por que precisamos deste pacote se ele pode ser tratado apenas definindo lib (o que devemos fazer de qualquer maneira)?

Minha solução foi adicionar lib: ["es2015", "dom"] em meu ts.config e também removi essa biblioteca, pois ela não era necessária quando adicionei as entradas lib.

Se os proprietários deste pacote não quiserem fazer nada com isso. Eu sugiro que você feche este problema com um comentário por que e como fazer isso corretamente para que todos saibam o que fazer.

Esta solução funcionou para mim na máquina Windows.

"lib": ["es2017", "dom"]
para meu compilerOptions em tsconfig.json resolveu esse problema para mim.

obrigado @ andy-ms

@Jtreu Obrigado pela sua resposta relatando gulp neste tópico.

Esse foi o problema no início deste projeto

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

e sua resposta ajuda a resolvê-lo.

Enviei um PR para reverter para a forma correta: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/19531

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

Por exemplo, se estou aplicando shims apenas aos símbolos ES6 com core-js as bibliotecas incluídas devem ser (pelo menos): es5 , dom , es2015.symbol

Alguém pode confirmar se minha interpretação está correta? Obrigado!
/ cc @ andy-ms

@cvsguimaraes Isso deve estar correto.

Isso ainda está quebrado? Estou recebendo error TS2304: Cannot find name 'PropertyKey'. e mais na 0.9.43

ATUALIZAÇÃO: Deixa pra lá, eu não percebi que fornecer um arquivo fonte para compilar na linha de comando como tsc priotractor.ts o impediria de ler o `tsconfig. Criei um novo arquivo tsconfig apenas para meu teste de transferidor, que inclui apenas o arquivo que estou tentando compilar e funciona bem agora.

Aqui está minha configuração, se ajudar alguém

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

Caso outra pessoa possa aprender com meu erro. Certifique-se de editar um tsconfig.json no diretório correto!

Depois de muito bater cabeça, percebi que estava editando a configuração na raiz do meu projeto em vez da configuração em root / src, que foi o que abri no VSCode. Depois de fazer as alterações recomendadas, ele funciona.

Atualizar o TypeScript para v2.6.1 e configurá-lo como uma versão para o VS Code resolveu o problema para mim.

@IAMtheIAM consertou para mim, obrigado

Tentei a maioria das configurações compilerOptions listadas aqui, com pouco ou nenhum sucesso ao longo de alguns dias. Droga, eu até atualizei o pacote typescript no meu sistema operacional!

A solução foi muito fácil de notar: não passe os arquivos TS para tsc diretamente, mas especifique-os em tsconfig.json e apenas chame tsc .

@shybovycha Por mais que isso resolva o problema, os documentos especificam que você pode e deve ser capaz de passar o arquivo diretamente para o comando. Sem essa mini 'correção', eu ainda estaria recebendo os erros de outra forma. Tenho as seguintes versões:

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