Concordou. Desejando algo como @SuppressWarnings do Java, em particular para o caso descrito aqui :

A seguir:

const typeMetadataKey = Symbol('type');

function type(name: string): PropertyDescriptor {
 return Reflect.metadata(typeMetadataKey, name);
}

Produz o erro: Unable to resolve signature of class decorator when called as an expression. .

Quando usado como abaixo:

class Person {
  @type('string')
  firstName: string;
}

O decorador funciona conforme o esperado e irá compilar, mas apresenta o erro acima.

Se você tem ideias sobre como isso pode ser resolvido, fique feliz em investigá-lo se alguém quiser indicar a direção certa.

Basta lançar (elenco não é um termo oficial, mas o mesmo conceito)

const foo: string = 7 as any;

É isso que você está procurando?

Acabei de dar um exemplo, não é realmente um caso (eu sei tudo sobre elenco), tenho outros casos, como
super sendo chamado após a primeira linha do construtor e outros problemas ...

• tornará a transição do JS + para o TS mais fácil, às vezes você altera uma lib e obtém toneladas de erros e deseja apenas limpar as coisas como você conhece como desenvolvedor pelo motivo ...

este é um recurso importante

Então, algo como // tslint:disable ?
Possivelmente até permitindo que você ligue / desligue verificações específicas que tsc executa?
_eg: _ const FooBar: string = 'rozzzly'; // tslint:disable-line camelcase

isso seria demais ...

Não sei ... Acho que pode estar fora do escopo de tsc . É para isso que servem os linters.

tem que ser capaz de "calar a boca" :)

Acho que há um caso a ser discutido para suprimir erros / avisos em recursos "experimentais", como decoradores, onde a API é um pouco volátil e os erros podem nem sempre ser precisos. Você obtém uma versão (muito específica) disso apenas usando o campo tsconfig "experimentalDecorators", mas ele suprime apenas um tipo de aviso.

Para bancar o meu próprio advogado do diabo, isso poderia encorajar novos usuários do TypeScript a suprimir os avisos que eles não entendem, em vez de aprender por que o aviso ocorre. E com os recursos experimentais, todo mundo é uma espécie de novo usuário - ter a capacidade de suprimir erros pode tornar os usuários complacentes com bugs em novos recursos, em vez de abrir problemas.

Em última análise, ainda quero que minha saída Syntastic seja limpa. O que significa suprimir o erro. Claro, isso seria _após_ eu abrir o problema para um possível bug e tentar aprender mais. ;)

O problema de "calar a boca" é que você não sabe o que ganha com "isso". assim let a:string = 1 a number ou string ?, e se houver outra declaração de a , ela se funde ou não? o que aconteceria se alguém capturasse o tipo desta variável, por exemplo, return {a} ; , eles deveriam ser atribuídos a { a : number } ou { a: string } , ou ambos.

uma coisa fundamental, os erros são todos ignóbeis. erros não bloqueiam a geração de saídas, nem o ferramental.

Existem diferentes mecanismos para permitir que você suprima a verificação de certas partes do seu código, por exemplo, any , asserções de tipo (casts) e declaração de ambiente.

então, por exemplo, se você tem uma biblioteca que tem uma definição "inválida", você pode simplesmente removê-la e substituí-la por declare module "blah" { export = any } . ou declare var $: any e você está pronto para ir.

Como costumo responder a essas solicitações, acho que seu problema não é suprimir o erro. o verdadeiro problema é que você obteve um erro que não considera útil. suprimir que não resolve o problema subjacente, apenas o cobre e tem ramificações de um estado inconsistente sem nenhum aviso. A solução certa é saber qual é o erro que você está obtendo. que biblioteca é essa? e por que o compilador está apresentando um erro inútil ...

E para isso precisamos saber mais sobre o seu caso de uso.

Fizemos alguns trabalhos no TS 2.0 para resolver alguns desses problemas subjacentes, por exemplo;

• Suporta declarações de módulo de ambiente abreviadas e caracteres curinga em nomes de módulo que permitem uma maneira fácil de desabilitar um módulo inteiro ou mesmo um conjunto de módulos, por exemplo, declare module "@angular\*";
• A resolução do módulo muda para permitir que você substitua de onde uma definição de módulo é carregada
• permitindo definições duplicadas com o mesmo tipo em arquivos .d.ts
• novo --skipLibCheck para não digitar verificar quaisquer .d.ts arquivos
• suporte para --typeRoots para permitir a substituição de onde os arquivos de declaração são carregados

basta usar qualquer um, é assim que "cala a boca", o mérito de fazê-lo (ou na verdade a falta dele) é uma questão diferente

let x: PieInTheSky = <any> 'cake is a lie';

ok, mas, novamente, o problema não é especificamente na transmissão

<any> dá a você vanila javascript com 100% de liberdade de todas as coisas irritantes do TypeScript, então o que mais você precisa?

no meu caso chamo super não como primeira linha de construtor e preciso acalmar o erro

Em vez de tentar forçá-lo a aceitar um antipadrão, por que não escrever, tente algo assim:

_ _ClassA.ts _

class A {
    constructor() {
        this.init();
    }
    protected init() {
        // does nothing by itself
    }
}

_ _ClassB.ts _

class B extends A {
    constructor() {
        super();
        console.log('rest of code from B\'s constructor');
    }
    protected init() {
        console.log('this runs before the rest of code from B\'s constructor');
    }
}

Isso é o que torna o texto datilografado tão incrível, _e também irritante_. Isso força você a escrever um código melhor e o torna um desenvolvedor melhor. Converter um projeto não é

no meu caso chamo super não como primeira linha de construtor e preciso acalmar o erro

E torne seu código incompatível com ES6 ... É exatamente por isso que o principal objetivo do TypeScript é tirar 👣: gun: de suas mãos.

Se o TypeScript não está interpretando algo certo, então deve ser corrigido em vez de "contornado". Agora, existem algumas coisas em que o TypeScript está agindo mais como um linter e ainda não há um conceito de "erro" versus "aviso". Posso ver os avisos de supressão quando eles vêm. Coisas como código após retorno e parâmetros não usados ​​deveriam ser avisos em minha opinião, porque eles são sintaticamente corretos (embora estúpidos).

aqui está outro caso em que eu adoraria ter esse recurso:

interface Animal {
  numberOfLegs: number;
  // a gazillion more properties
}

class Dog implements Animal {
  breed: string;

  constructor(animal: Animal, breed: string) {
    Object.assign(this, animal);
    this.breed = breed;
  }
}

No momento, há um erro de ts:

[ts] A classe 'Dog' implementa incorretamente a interface 'Animal'
A propriedade 'numberOfLegs' está faltando no tipo 'Dog'

Como você pode ver, o compilador está totalmente errado, mas não quero (e não deveria ser forçado a) copiar todas as propriedades da interface apenas pelo compilador.

@DethAriel Basicamente, o que você está pedindo é uma maneira de expressar os efeitos colaterais pós-condição no sistema de tipos. Isso é interessante, mas tenho a sensação de que isso levaria a um código terrivelmente complicado.

@aluanhaddad Sim, entendi

Basta usar uma combinação interface + classe

interface Animal {
  numberOfLegs: number;
  // a gazillion more properties
}

interface Dog extends Animal {
}

class Dog  {
  breed: string;

  constructor(animal: Animal, breed: string) {
    Object.assign(this, animal);
    this.breed = breed;
  }
}

Thx, @mhegazy , funcionou mesmo

E se o erro não puder ser <any> ed afastado?

Estou usando a sintaxe de ligação experimental conforme discutido aqui https://github.com/Microsoft/TypeScript/issues/3508 e, além de não usá-la, não consigo fazer com que o compilador ignore o erro em cada linha antes de cada :: operator ( TS1128: Declaration or statement expected )

Estou usando a sintaxe de ligação experimental

isso é realmente mais do que descartar um aviso. O analisador não suporta isso, então a árvore resultante está completamente errada, todos os recursos do compilador a partir deste ponto não funcionarão, portanto, nenhuma inferência de tipo, nenhuma verificação de compatibilidade, nenhuma formatação, nenhuma conclusão, nada. portanto, seria melhor ignorar todos os erros ou apenas trabalhar em um arquivo .js.

No momento, estou convertendo um grande projeto JS em texto digitado e depois de fazer a conversão quando executo o comando gulp build , vejo cerca de 2.000 erros de TS durante a compilação e a maioria dos erros está relacionada à propriedade não definida em uma classe ou módulo não definiram. Acho que deve haver alguma maneira de suprimir esses tipos de erros à medida que os arquivos JS de saída estão sendo gerados.

Este é exatamente o meu caso também, eu converto um aplicativo construído com o design de módulos como propriedades pré-ES6, então eu tenho um ENORME app.namespace1.namespace2.something.views.view -like objeto global.

Eu reescrevo parte dele e CONFIO com o objeto global app. * E seus diferentes subelementos em meu código. Tudo que recebo é uma massa de avisos "Não é possível encontrar o namespace 'app'".

Refatorei todas as minhas dependências globais para globalProxy.ts, então este é o único lugar que recebo os avisos, mas seria INCRÍVEL adicionar // TS-NO-WARNINGS no topo deste arquivo para limpar o console das mensagens óbvias ...

Os erros de TS não bloqueiam a geração do código. Você pode optar por ignorá-los, mas o que eles estão dizendo é que o compilador não pode afirmar a exatidão do seu código.

@ zeeshanjan82 por que não usar --allowJs e migrar arquivo por arquivo? Com essa configuração, você não obterá erros de tipo de fontes JavaScript. Você também pode usar uma declaração de ambiente curinga para suprimir erros de resolução de módulo como
_globals.d.ts_

declare module '*';

Aqui está outro caso de uso para supressão de erros.

Os mantenedores da biblioteca do momento se esqueceram de adicionar isoWeek como uma string válida ao parâmetro enum para os métodos startOf e endOf . Ele foi corrigido em uma versão subsequente, mas, ao fazer isso, eles refatoraram completamente a maneira como essas unidades são tratadas, o que causaria muito retrabalho de nossa parte.

Então, corrigimos a versão do momento no lugar, mas agora essencialmente não podemos usar isoWeek por causa de erros de lançamento de TS. Tão presa entre uma rocha e um lugar duro no momento.

você pode apenas adicionar uma cópia local. diga algo tão simples como:

// ./overrides/moment.d.ts
declare module "moment";

// tsconfig.json
{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5",
        "baseUrl": ".",
        "paths": {
            "moment": ["overrides/moment.d.ts"]  // override definition for moment
        }
    }
}

agora, o compilador verificará sua cópia local de override/moment.d.ts vez daquela que vem com o pacote. obviamente, esta pode ser uma cópia local do arquivo de declaração de momento ou um pequeno conjunto de coisas que você precisa.

Não tenho tempo e desejo de manter minhas próprias definições de tipagem para bibliotecas de terceiros;)

Não tenho tempo e desejo de manter minhas próprias definições de tipagem para bibliotecas de terceiros;)

E isso está perfeitamente bem. apenas use declare module "moment"; que é o equivalente a declare var $: any para módulos, e o compilador não o incomodará com isso novamente.

A sugestão de @mhegazy é muito boa. Isso levará cerca de 20 segundos para fazer isso. A propósito, com relação ao momento, eles se esqueceram de algumas unidades que eu estava usando e estavam muito abertos para aceitar meu pedido de pull.

A desvantagem de adicionar declare module "moment"; é que você não terá mais qualquer IDE Intellisense ou verificação de tipo estático para qualquer código relacionado ao momento. E os any s que surgem tendem a vazar no código circundante, fechando também muitas verificações estáticas. É um preço alto a pagar por suprimir erros relacionados a um único valor enum problemático.

@aluanhaddad havia uma solicitação de pull aberta para corrigir o problema, mas foi fechada em favor de outra, que introduziu mudanças importantes (e ainda não adicionou suporte para isoWeek ), então não tenho certeza do que aconteceu lá .

A questão é que essas questões tendem a surgir com mais frequência no futuro com a adoção do Angular 2, etc., portanto, posso imaginar que uma maneira de suprimir erros específicos seria útil.

Tenho este problema com uma biblioteca de núcleo de nó (rede, nó 6.9 LTS):

server = net.createServer({ pauseOnConnect: true }, function(connection) { ... }) 
// [ts] severity: 'Error'
message: 'Argument of type '{ pauseOnConnect: boolean; }' is not assignable to parameter of type '{ allowHalfOpen?: boolean; }'.
  Object literal may only specify known properties, and 'pauseOnConnect' does not exist in type '{ allowHalfOpen?: boolean; }'.'

E também com a biblioteca ioredis:

var redis = new Redis(CONFIG.redis); 
// [ts] severity: 'Error'
message: 'Only a void function can be called with the 'new' keyword.'

Como @yortus e @adamreisnz apontaram, este é um problema comum, pois os arquivos de definição nem sempre são atualizados corretamente. Além disso, se você tivesse que sacrificar os benefícios do TS usando declare module "x"; por que usaria o TS em primeiro lugar?

Você também pode aumentar o módulo com os tipos que faltam para não perder a inteligência.

Bem, quando escrevo:

if (typeof Symbol === "function" && Symbol.match) {
  // ...
}

O compilador de texto digitado sempre relata um erro Cannot find name 'Symbol' se target for es5 , embora este código realmente funcione bem como eu esperava.

Portanto, concordo que precisamos urgentemente de algumas diretivas de controle trabalhando nas linhas de comentários.

declare var Symbol: any;

@ gdh1995 @mhegazy Ou apenas use a correção real que é definir o sinalizador lib como es2015 .

Obrigado @mhegazy . Acho que funciona bem:

declare var Symbol: {
  (description?: anyNotSymbol): symbol;
  readonly match: symbol;
};

@DanielRosenwasser Embora es2015 adicione esses recursos úteis, meu projeto é limitado para ser compatível com es5 e Symbol deve ser evitado em outros arquivos.

O que eu não entendo agora é que o compilador TypeScript me dá erros mesmo quando eu escrevo typeof Symbol === "function" . Algum conselho?

Um caso que adoraria apresentar é para simulação de dependências:

// Test.ts

// Component to test
import {ComponentToTest} from './ComponentToTest';

// Dependency of ComponentToTest to mock
import {Dependency} from './Dependency';

// Mock to replace it with
import {MockedDependency} from './MockedDependency';

Dependency = MockedDependency;

Este código tem o efeito desejado de fazer com que a dependência seja simulada dentro do componente testado, mas o TypeScript lança um óbvio "Não é possível atribuir a 'Dependência' porque não é uma variável." erro.

Tenho certeza de que a resposta será que estou latindo para a árvore errada e deveria estar usando algo como inject-loader mas, por experiência própria, essas soluções A) são difíceis de trabalhar / nem sempre trabalho e B) não são tão simples como os anteriores. Como o OP mencionou, às vezes o desenvolvedor sabe melhor. Eu sei que esta é uma solução hacky, mas funciona e eu adoraria que o TS calasse a boca neste caso.

Este código tem o efeito desejado de fazer com que a dependência seja simulada dentro do componente testado, mas o TypeScript lança um óbvio "Não é possível atribuir a 'Dependência' porque não é uma variável." erro.

este é um erro no ES6. então, em algum momento no futuro, quando os engines suportarem módulos ES6 nativamente, seus testes precisarão ser reescritos.

Alternativamente, você pode fazer seu ComponentToTest aceitar um argumento para Dependency , e seus testes podem passar nisso, ou ter um gancho de teste que permite que você substitua o valor de Dependency antes de invocar métodos em ComponentToTest .

este é um erro no ES6. então, em algum momento no futuro, quando os engines suportarem módulos ES6 nativamente, seus testes precisarão ser reescritos.

Ah, é justo eu desistir, pois esse requisito é tangencial a esta questão.

Alternativamente, você pode fazer seu ComponentToTest aceitar um argumento para Dependência, e seus testes podem passar ...

Acho que é isso que acabamos fazendo. É muito chato ter que redefinir a API de uma classe para torná-la testável, mas acho que esse não é um problema exclusivo do TS.

Obrigado pelo feedback, @mhegazy

Eu gostaria de substituir a verificação no tipo de argumento de uma função.

Meu caso de uso é bastante simples, tenho uma função como esta:

function isValidId(s: string): boolean {}

que verificam se uma string segue alguma regra.
É usado internamente e para validar a entrada do usuário - gostaria de escrever testes para ver se retorna false quando o usuário insere algo que não é uma string.

A rigor, a função pode aceitar qualquer coisa como entrada porque é capaz de gerenciá-la, mas como também a usamos internamente, gostaria de especificar que queremos uma string

Portanto, eu gostaria de algo para suprimir o erro sobre o formato errado nos testes

@rpadovani use apenas any :

expect(isValidId(78 as any)).toBe(false);

Eu poderia usar isso também. Temos uma situação em que foo (bar: any, baz: any) é definido como parte de um framework, mas em algumas implementações de foo, bar não é usado. Com a verificação de erro de texto digitado ativada, isso gera um erro porque uma variável não utilizada é declarada. Deve ser declarado, porque outras versões de foo, bar são usadas.

@benjaminabbitt Parece que foo (_bar: any, baz: any) funciona para você: um nome começando com "_" não é forçado a ser usado.

Adicionar: acredito que a capacidade de substituir / ignorar erros especiais é importante.

Algo desafiador aqui é que as pessoas continuam aparecendo dizendo que desejam suprimir erros, postando trechos de código e obtendo soluções eficazes no código para silenciar esses erros (ou descobrir que seu código realmente tem um problema). É difícil projetar esse recurso sem saber a aparência de um erro realmente problemático ou entender quais são os erros que as pessoas desejam suprimir globalmente.

Qual é a maneira apropriada de lidar com o código javascript de terceiros que desejamos incluir em nossos projetos?

Considere o seguinte cenário. Há uma enorme biblioteca que não foi publicada no npm e, mesmo que fosse, usar a biblioteca como está faria nosso aplicativo carregar muito código morto (o tremor de árvore não pode ajudar porque eles anexam tudo a um objeto).

Vamos supor que, neste caso, não valha a pena extrair esse trecho de código e publicá-lo em npm. Que outras opções temos?

Em minha tentativa de usar esta biblioteca, extraí o código de que meu projeto precisa e o incorporei ao projeto como um arquivo de texto digitado. O problema com isso é que o texto digitalizado verifica esse arquivo e agora fornece muitos erros para ele.

Para esta situação, seria ótimo ter o comentário /* ts:disable */ no topo para que o texto digitado soubesse que não nos importamos com possíveis erros no arquivo.

Observe que meu projeto não confirma mais nenhum arquivo javascript e, mesmo que o fizesse, o processo de construção ficaria mais complicado ao tentar acomodar um javascript no fluxo.

Alguém tem algum conselho sobre como lidar com o código javascript de terceiros que precisa ser hospedado em um projeto typescript?

Alguém tem algum conselho sobre como lidar com o código JavaScript de terceiros que precisa ser hospedado em um projeto typescript?

não os migre. deixe os arquivos .js como estão. crie um arquivo .d.ts para eles. isso é o que os arquivos .d.ts representam.

o arquivo .d.ts pode começar com algo tão básico quanto:

declare var $: any;

em seguida, adicione-o conforme achar adequado e conforme suas necessidades aumentem.

Essa é uma boa opção se eu estiver enviando arquivos js. Existe alguma outra opção para projetos que ignoram arquivos js?

Essa é uma boa opção se eu estiver enviando arquivos js. Existe alguma outra opção para projetos que ignoram arquivos js?

Não tenho certeza se entendi a pergunta. Os arquivos JS são ignorados por padrão. então você opta por adicionar arquivos. novamente minha recomendação é, para código externo que não é seu, ou para código legado que você não pretende alterar, não se preocupe em convertê-lo para TS. comece escrevendo um arquivo .d.ts para eles. para isso, comece simples, com any 's e adicione conforme você avança.

Eu deveria ter dito que os arquivos js não estão sendo enviados ao repositório git, daí a razão de colocar o código em um arquivo ts. De qualquer forma, vou tentar seguir o caminho que você mencionou e forçar o commit desses arquivos js.

você não precisa confirmar os arquivos .js. digamos que você esteja usando uma dependência, digamos, reagir. normalmente você não comprometerá react-0.12.0.js em seu repo, mas deseja usá-lo. normalmente você incluiria isso em uma tag sccript de um CDN, por exemplo. digamos também que @types/react não existe ou você não deseja usá-lo. então, em seu projeto, adicione um novo arquivo de declaração, chame-o de declarations.d.ts e adicione:

declare module "react"; // just saying the module is of type any

isso diz ao compilador que existe um módulo chamado "react" e ele apenas o usará, sem a necessidade de incluir nenhum arquivo .js.

Portanto, se eu quiser usar um pequeno pedaço de javascript (que não está disponível via npm / CDN) e decidir enviá-lo para minha base de código, tenho 2 opções:

Opção 1 : mantenha o código original como um arquivo .js e mantenha um arquivo .d.ts para manipular os tipos.

Acho que isso não funciona para @ jmlopez-rod porque ele não deseja enviar código javascript para seu repositório e, mesmo que o fizesse, disse que isso tornaria seu processo de construção complicado.

Opção 2 : embrulhe o javascript em typescript e lide com todos os erros de typescript.

Isso contorna o "complicado processo de construção" porque tratará o código como texto digitado ... mas agora temos erros de texto digitalizado e voltamos à discussão original neste tópico de discussão. Este é um caso de uso válido para desabilitar erros de digitação?

Acho que isso não funciona para @ jmlopez-rod porque ele não deseja enviar código javascript para seu repositório e, mesmo que o fizesse, disse que isso tornaria seu processo de construção complicado.

não tenho certeza se entendi por que isso complica seu processo de construção. você tem um arquivo "library.js" e "website.js" , você decide mover "website.js" para "website.ts", basta chamar tsc website.ts --outFile website.js e agora estamos de volta onde está tudo começou com dois arquivos .js. então não vejo porque é mais complicado do que antes .. é apenas uma etapa extra de construção no topo da cadeia.

Isso contorna o "complicado processo de construção" porque tratará o código como texto digitado ... mas agora temos erros de texto digitalizado e voltamos à discussão original neste tópico de discussão. Este é um caso de uso válido para desabilitar erros de digitação?

Não tenho certeza se entendi completamente por que você decidiu mudar este arquivo para ts e integrá-lo ao seu projeto, deixar os tipos dele fluírem para seus outros componentes, construí-lo junto com o seu código, mas mantê-lo em um padrão diferente.

Pode ser um exemplo seria útil aqui. como @RyanCavanaugh observou , parece-me que todos esses problemas têm maneiras bem definidas de informar ao compilador sobre os tipos e evitar erros em vez de desabilitar todos os erros e jogar o bebê junto com a água do banho.

eu não conseguia entender por que essa declaração ambiental não está funcionando para mim.
Eu já defini a definição de caminhos para o tsconfig.json assim
"paths": { "js-xlsx": ["./xlsx.d.ts"] }
mas ainda encontro esse erro de módulo não encontrado.
Eu tentei adicionar 'fs', 'fs-extra' e as bibliotecas 'js-xlsx', todas elas não responderam às minhas declarações ambientais, castings ou adicionando quaisquer tipos como aqui declare var $: any;
@mhegazy

você não precisa confirmar os arquivos .js. digamos que você esteja usando uma dependência, digamos, reagir. normalmente, você não fará commit do react-0.12.0.js em seu repo, mas deseja usá-lo. normalmente você incluiria isso em uma tag sccript de um CDN, por exemplo. digamos também que @ types / react não exista ou você não queira usá-lo. então, em seu projeto, adicione um novo arquivo de declaração, chame-o de declarations.d.ts e adicione:

declare o módulo "react"; // apenas dizendo que o módulo é do tipo qualquer
isso diz ao compilador que existe um módulo chamado "react" e ele apenas o usará, sem a necessidade de incluir nenhum arquivo .js.

A propósito, eu sei que a biblioteca fs-extra tem a definição de tipo como @ types / fs-extra e para o js-xlsx temos bibliotecas ts-xlsx, mas isso é tão estranho que esses truques não estão funcionando para mim :(

A propósito, eu sei que a biblioteca fs-extra tem a definição de tipo como @ types / fs-extra e para o js-xlsx temos bibliotecas ts-xlsx, mas isso é tão estranho que esses truques não estão funcionando para mim :(

Acho que há algo mais acontecendo com o seu projeto.

c:\test\9448>npm install @types/fs-extra
[email protected] c:\test\9448
`-- @types/[email protected]
  `-- @types/[email protected]

npm WARN [email protected] No description
npm WARN [email protected] No repository field.

c:\test\9448>type a.ts
import { rmdir } from "fs-extra";
rmdir("c:/test");

c:\test\9448>type tsconfig.json
{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5"
    }
}
c:\test\9448>tsc --v
Version 2.2.0

c:\test\9448>tsc

c:\test\9448>echo %ERRORLEVEL%
0

Sim, talvez, mas o principal problema que eu não conseguia entender é por que não consegui suprimir os avisos do compilador com os métodos fornecidos. A propósito, tenho https://github.com/AngularClass/angular2-webpack-starter , base para meu projeto

Suprimir erros não significa necessariamente introduzir antipadrões.

Estou recebendo um erro incorreto,

error TS1005: '{' expected.

neste JSX perfeitamente bom:

<motor-node ref      = 'menu'
    absoluteSize     = `0, ${this.MENU_BAR_HEIGHT}, 0`
    >
    {menu}
</motor-node>,

Ele reclama que a string do modelo precisa de { . Idealmente, isso deveria ser corrigido, mas, até lá, gostaria de ser capaz de suprimir o erro por um bom motivo .

@trusktr , este erro é um erro de análise. suprimi-lo não altera o fato de que o compilador não entende o código a partir desse ponto e a forma do restante do arquivo fica em um estado indefinido. isso significa que mesmo que este erro seja abafado, os tipos inferidos, bem como outros erros gerados neste arquivo ou outros não estão corretos.

Dito isto. De acordo com a especificação JSX :

JSXAttributeValue:

"JSXDoubleStringCharactersopt"
'JSXSingleStringCharactersopt'
{AssignmentExpression}
JSXElement

Portanto, temo que o erro esteja correto e um atributo JSX não possa ter um literal de modelo de string. você pode usar absolteSize = {...} vez disso

este erro é um erro de análise

Sim, é por isso que deve ser consertado.

A saída é absoluteSize: "0, " + this.MENU_BAR_HEIGHT + ", 0" , o que me diz que as coisas do compilador estão bem.

Oh. Desculpa, então. Eu sinto falta de entender seu comentário. Achei que você queria que o erro fosse silenciado.

Eu fiz, mas você está certo, talvez seja melhor eu viver apenas adicionando {} .

No TS 2.1 (VS2017 RC), recebemos avisos provenientes da pasta de arquivos JS das bibliotecas (em / Scripts) - como o TS7027. Seria bom ser capaz de suprimir avisos / erros dos arquivos de biblioteca ou, pelo menos, suportá-los em algum tipo de arquivo de supressão global (semelhante a C # GlobalSupressions.cs)

No TS 2.1 (VS2017 RC), recebemos avisos provenientes da pasta de arquivos JS das bibliotecas (em / Scripts) - como o TS7027.

Para código inacessível (TS 7027), defina --allowUnreachableCode ou defina-o em seu tsconfig.json .

Mas é possível aplicá-lo apenas a arquivos de biblioteca. Porque para "meu código" eu preciso!

usando --alowJs torna-se seu código. o compilador irá sugá-lo, irá transpilá-lo para o destino sugerido, irá concatená-lo se você usar --outFile .. apenas que ele tem uma extensão .js. se for um código de "biblioteca", recomendo criar um .d.ts para ele e incluí-lo.

Não estou ciente de que ativamos --allowJs - no VS2015 o mesmo projeto que não embaralha jquery.js, arquivos react.js em Scripts (e de fato referenciado apenas a partir da página html por

let { value } = browser.waitForPromise(() => {
    return browser.executeAsync(function (method, name, resolve) {
        require(['patron.Locator/patron.Locator.Manager'], function (locator) {
            resolve(result);
        });
    }, method, name);
});

No meu caso, a primeira linha escrita em TypeScript, a segunda linha escrita em JavaScript. Eles são executados em contextos diferentes e não quero modificar o código JavaScript.
Portanto, precisamos de uma nova opção como /* ts-disable */ /* ts-enable */ (semelhante ao eslint)

No meu caso, a primeira linha escrita em TypeScript, a segunda linha escrita em JavaScript. Eles são executados em contextos diferentes e não quero modificar o código JavaScript.

não tenho certeza se entendi o que você quer dizer com "segunda linha escrita em JavaScript"? você passa toda a instrução para o compilador ou não?

não tenho certeza se entendi o que você quer dizer com "segunda linha escrita em JavaScript"? você passa toda a instrução para o compilador ou não?

Não quero modificar esse código porque ele deve ser passado para o servidor Selenium como está .

Não quero modificar esse código porque ele deve ser passado para o servidor Selenium como está.

se estiver em um arquivo .ts, será transformado pelo compilador. O compilador remove as anotações de tipo para você.

Independentemente disso, para este exemplo, tudo que você precisa é declare var browser: any; e você não deve obter nenhum erro. consulte Playground para obter uma amostra.

se estiver em um arquivo .ts, será transformado pelo compilador. O compilador remove as anotações de tipo para você.

Preciso de uma garantia de que um determinado código foi executado sem alterações no IE6 e em outros navegadores antigos.
Por exemplo, Node.js segue o sistema de módulo CommonJS, mas my require é uma função personalizada definida por outros desenvolvedores em suas páginas. É por isso que gostaria de incluir esse código sem nenhuma pós e pré-modificação. É importante para mim e para minha equipe.

Independentemente disso, para este exemplo, tudo o que você precisa é declarar var browser: any; e você não deve obter nenhum erro. consulte Playground para obter uma amostra.

Na verdade, o objeto de navegador é o objeto mais popular em meu projeto e não há nenhuma razão para ignorá-lo. O método browser.execute também possui declaração de tipo próprio.

agora não tenho certeza se entendi qual é o problema então. Qual é o erro que você esta tendo?

Meu código é executado em diferentes contextos: nó e navegador. Os problemas atuais para o segundo contexto são anotações de tipo e modificação de código.

let { value } = browser.waitForPromise(() => { // node
    return browser.executeAsync( // node
            function (method, name, resolve) { // browser
        require(['patron.Locator/patron.Locator.Manager'], function (locator) {  // browser
            resolve(result);  // browser
        });  // browser
    }, method, name); 
});

Aqui está uma implementação simples do método browser.executeAsync :

browser.executeAsync  = (...args) => {
   let script = args.shift();

   RPC.Selenium('/session/:sessionId/execute', {
         script: `return (${script}).apply(null, arguments)`, 
         args
    });
}

Como você pode ver, eu uso o TypeScript para testes de integração.

Qual é a mensagem de erro?

Erros padrão:

TS2345: Argument of type 'string[]' is not assignable to parameter string
TS7006: Parameter 'error' implicitly has an 'any' type
TS7006: Parameter 'attach' implicitly has an 'any' type
TS7006: Parameter 'message' implicitly has an 'any' type
TS7006: Parameter 'model' implicitly has an 'any' type

E assim por diante...

Defina require corretamente.

declare function require(v: string[]): any;

Defina exigir corretamente.

Eu não posso. No meu caso, o método executeAsync contém código para projetos de terceiros e existem diferentes variações para require s. O código acima é apenas uma função de centenas.
Meu desejo é muito simples - deixe-me excluir alguns códigos quando eu precisar :)

você pode colocar declare function require(v: string[]): any; localmente. por exemplo:

// module a.ts
export var ...

declare function require(v: string[], callback: Function);

let { value } = browser.waitForPromise(() => { 
    return browser.executeAsync( 
        function (method, name, resolve) { // browser
            require(['patron.Locator/patron.Locator.Manager'], function (locator) {  // OK
                resolve(result);  
            });  
        }, method, name);
});

você também pode apenas lançar para any quando necessário:

let { value } = browser.waitForPromise(() => { // node
    return browser.executeAsync( // node
        function (method, name, resolve) { // browser
            (<any>require)(['patron.Locator/patron.Locator.Manager'], function (locator) {  // browser
                resolve(result);  // browser
            });  // browser
        }, method, name);
});

Isso deve produzir um código idêntico.

No meu caso, tenho uma classe abstrata privada (não exportada) que se destina apenas a ser estendida por duas classes:

abstract class IParent {
  static fromConfig(config: ParentConfig): IParent {
    // actual code is 20 lines long, not this simple
    // this throws "Cannot create an instance of the abstract class 'Parent'"
    return new this().applyConfiguration(config);
  }
  abstract method1(): void;
  ...
}

export class FirstChild extends IParent {
  specificMethodForFirstChild() { ... }
  method1() { ... }
  ...
}

export class SecondChild extends IParent {
  specificMethodForSecondChild();
  method1() { ... }
  ...
}

Uso:

let first = FirstChild.fromConfig({ ... });
let second = SecondChild.fromConfig({ ... });

// this runs successfully:
(first as FirstChild).specificMethodForFirstChild();
(second as SecondChild).specificMethodForSecondChild();

Mas no método fromConfig() I get "Não é possível criar uma instância da classe abstrata 'Parent':

Código de parque infantil

• Posso duplicar os métodos estáticos e fazer com que eles chamem uma função comum, mas parece bastante estúpido quando já tenho um código funcionando.
• Não posso tornar a classe não abstrata porque as subclasses aplicam a implementação do método.
• Posso remover os métodos abstratos, mas os uso para impor a mesma interface nas subclasses.
• Posso usar uma interface separada para aplicá-lo, mas a superclasse não caberá na interface e é o tipo retornado pelo método estático.
• Não tenho intenção de chamar o método estático na classe abstrata, só quero instanciar uma classe diferente nas diferentes subclasses

O compilador não impõe que os construtores da classe derivada tenham a mesma assinatura da base. em outras palavras, o construtor da classe derivada pode ter mais argumentos necessários do que a base. usar new this() pressupõe que todos os construtores derivados não terão parâmetros obrigatórios; e isso é algo não verificável.

Se você tem certeza de que está correto, considere lançar como new (<any>this)(x, y);

Bom ponto, eu não vi isso. Sua sugestão realmente funciona, vou considerar os perigos, obrigado.

Existe uma maneira de silenciar o Module ... was resolved to ..., but '--allowJs' is not set ? no meu caso de uso, há um sistema de compilação que cuida disso e não preciso passar todo o meu código pelo TSC, então gostaria de silenciar esses erros.

'declare o módulo "someModule";' em um de seus arquivos .d.ts.

Ou instale o pacote @types correspondente, se houver.

Tenho outro exemplo de quando isso seria útil:

const Button = (
  content: contentTypes,
  action: React.EventHandler<React.MouseEvent<HTMLDivElement>>,
  disabled: boolean
): JSX.Element => (
  <div className={`Button disabled-${disabled}`} onTouchStart='' onClick={ !disabled ? action : undefined } >
    { content }
    <div className='background'></div>
  </div>
);

Isso gera um erro porque onTouchStart não aceita uma string como parâmetro verdadeiro. No entanto, onTouchStart='' corrige o comportamento quebrado do CSS em dispositivos de toque relacionados a certas regras de CSS. Não gostaria de desabilitar esse erro globalmente ou redefinir alguns tipos de JSX. Eu gostaria apenas nesta linha para remover este erro.

onTouchStart={<any>''}

Isso realmente não resolve.
Eu recebo este erro:

Está quebrado na sintaxe tsx

onTouchStart={'' as any} , em vez disso (esqueci o JSX usa sintaxe de asserção alternativa)

@RyanCavanaugh o código gerado se qualificaria como um caso de uso legítimo para este recurso? Estou usando o swagger codegen para criar um cliente API para um serviço de nó. Também estou usando os tipos de cliente gerados em meu servidor, já que ele transforma as definições de swagger em interfaces TypeScript, portanto, é a maneira mais fácil de garantir que estou respeitando meu próprio contrato de swagger.

O código gerado é um pouco estranho e tem blocos como este:

let contentTypeHeader: Dictionary<string>;
if (contentTypeHeader) {
    fetchOptions.headers = contentTypeHeader;
}

Isso dá um erro se strictNullChecks estiver ativado, então desativei o sinalizador para todo o projeto. O que é péssimo. Não quero analisar o texto datilografado gerado e modificá-lo, mas estaria preparado para inserir algo como <tsc strictNullChecks=false /> no início do arquivo (semelhante à sugestão de

Isso não seria uma solicitação de mudança para o gerador de código swagger para produzir código compatível com strictNullChecks?

@mhegazy com certeza - mas este é apenas um exemplo de algo assim. A geração de código é útil de várias maneiras no TypeScript (mais do que no JavaScript). Portanto, idealmente haveria uma maneira de não forçar as pessoas a arrastar seus próprios projetos para os padrões de seu código gerado.

Mas eles são :) o código que você obtém de sua ferramenta de geração automática resulta em tipos que fluem para sua compilação. se a ferramenta de geração de código ignorar --strictNullChecks , seu código está observando tipos não enganosos.
desativar as verificações está apenas abafando o alarme de incêndio. a questão não é o alarme, é o que está causando o incêndio em primeiro lugar.

@mhegazy Não há problema em abafar o alarme de incêndio no código gerado por uma ferramenta muito bem testada. O código é bom, eles apenas não estão usando recursos de linguagem de última geração e não deveriam.

Que tal um exemplo menos controverso - e se o código gerado tiver um local não utilizado? Isso não causa nenhum dano ao meu código - exceto no caso em que tenho que desligar noUnusedLocals no tsconfig - que é o que estou fazendo agora.

Que tal um exemplo menos controverso - e se o código gerado tiver um local não utilizado? Isso não causa nenhum dano ao meu código - exceto no caso em que tenho que desligar noUnusedLocals em tsconfig - que é o que estou fazendo agora.

se você não se importar com o código gerado, ele deve estar em .js com um .d.ts complementar. dessa forma, você pode verificar contra ele, mas não precisa compilá-lo.

o compilador typescript não parece gostar dos mixins de underscore.js usados ​​com chain.

_.mixin () {sortFunciton: sortFunc (), otherChainFunc: otherFunction ()}

....

someVal = _.chain (someArray)
.sortFunction ()
.otherChainFunc ()
.valor();

...

Um exemplo muito fácil é quando você cria um listener para clique, por exemplo com @HostListener() para Angular, assim:

@HostListener('click', ['$event'])
onClick(event: MouseEvent) {
    // Code here...
}

Se eu ativar noUnusedLocals , tenho o seguinte erro:

ERROR in ./src (20,13): 'onClick' is declared but never used.

Posso deixar o compilador ignorar isso?

@JeremyCarlsten

_.mixin(){sortFunciton: sortFunc(), otherChainFunc: otherFunction()}

parece um código inválido.

@leocaseiro Por que precisa ser privado? Neste caso onClick é um método que o angular acabará usando. Um problema semelhante sempre acontece quando declaramos variáveis ​​privadas que usamos em um modelo. Se você usá-los no modelo, simplesmente torne as variáveis ​​públicas. Faz sentido, já que você está deixando o angular usá-los.

Olá @ jmlopez-rod, você está certo.

Interessante que como público, está passando agora! Eu realmente aprecio sua ajuda.

@leocaseiro public é o nível de visibilidade padrão, então você não precisa especificá-lo.

Peço desculpas antecipadamente se soar negativo - posso ter perdido algo (novo no TS).
Outro exemplo (estou usando apenas TS para produzir ES5 - sem fundição, declaração, interface)

// do-as-i-tell-you-start
const factory = () => {
  const _this = [];
  let _value;
  Object.defineProperties(_this, {

    // Error: Property 'getset' does not exist on type 'any[]'.
    // true at at creation but not when used – don't MOM me!
    'method1': { value(){ return _this.getset; } },   

    // Works with property strings – I don't want this
    'method2': { value(){ return _this['getset']; } }, 

    'getset': { get(){ return _value; }, set(value){ _value = value } },
  });
  return _this;
}

verdadeiro na criação, mas não quando usado - não me mamãe!

É exatamente para isso que o TypeScript foi projetado. Se você não deseja usar tipos e fundição, por que está usando o TypeScript? Conforme apontado várias vezes neste tópico, ele ainda emitirá o código, portanto, você já ignora os erros por sua própria conta e risco. Por que tentar simplificar o TypeScript, com que propósito?

Por que tentar simplificar o TypeScript, com que propósito?

É sobre mover uma equipe de ES5 => ES6 (Babel ou TS) => TS em toda a sua glória - em passos de bebê.

Minha impressão foi que o TS é um acréscimo ao JS, permitindo que você avalie em que nível você está.
O motivo da minha reclamação é que o exemplo fictício fornecido lança um erro e, portanto, _does
não produz ES5_. O linting de passagem IMO não deve ser obrigatório para transpilar.

A menos que você não emita em caso de erro, ele emitirá. Portanto, ele produz ES5.

Não funcionou - mudou para Babel - funcionou

tsc pode ser configurado para emitir a saída independentemente dos erros de tipo, observe a opção noEmitOnError .

Se você estiver usando o ts-loader, ele também terá uma nova opção transpileOnly onde simplesmente transpilará e não mostrará nenhum erro.

@trusktr obrigado - vou tentar :-)

erros não bloqueiam a geração de saídas, nem o ferramental

Isso não é verdade. Temos uma configuração (bastante comum - vem do inicial) no webpack que na construção de produção trava e NÃO produz nada. E deveria ser assim - o compilador relata o (s) erro (s), o programador volta e os corrige. Por que usar tipos quando a equipe inteira os ignora porque o build está "funcionando"? Da mesma forma, se tsc falhar na compilação, a atualização automática não funciona (o plugin foi escrito intencionalmente dessa forma - ele não atualiza se o seu código estiver errado [ou considerado errado pelo compilador]).

Suprimir erros é útil quando há um bug no tsc. Por exemplo, isso deve compilar:

interface A {
  isEmpty(x: any[] | string | object): boolean;
}

const a: A = <A>{};
a.isEmpty({a: 1});

mas na versão atual do TS ele falha.

Editar: chamada de função fixa (linha errada copiada)

Por

a.isEmptyObject ({a: 1});

você quer dizer

a.isEmpty ({a: 1});

?

Ai sim. Linha errada copiada: /.

Suprimir erros é útil quando há um bug no tsc.

Um bug que impede a emissão deve ser corrigido. É altamente improvável que a capacidade de ignorar um erro faria com que o tsc emita repentinamente algo quando ele tem um bug que o faz travar.

Tenho uma importação parecida com esta:

import * as reducers from "./**/reducer.ts"

Eu uso o TypeScript primeiro, depois o Babel. Eu tenho um plugin babel que trata * em importações como um padrão glob. O TypeScript gera um erro reclamando sobre .ts e, se .ts for removido, ele não poderá encontrar o módulo.

Não tenho certeza de como resolver isso, mas meu primeiro pensamento foi suprimir o (s) erro (s) relacionado (s) a esta linha. Tentei mapear o módulo na configuração, mas * é tratado como um caractere curinga e não pode ser escapado.

@lukescott em a .d.ts dentro do escopo do compilador:

declare module './**/reducer' {
  export = {
    [reducer: string]: () => void; /* or whatever */
  };
}

Outro exemplo de como isso seria útil:

const req = https.request({
        host: 'www.google.com',
        method:'GET',
        path:'/',
        port: 443,
}, (res) => { 
    console.log(res.connection.getPeerCertificate());
});

O getPeerCertificate diz que não existe devido a definições incorretas no nó https ( também este ).

Ele ainda compila e funciona com o grande sublinhado vermelho, mas seria muito bom fazer

console.log(res.connection.getPeerCertificate()); //ts:disable-line

@trusktr
Opa, parece que baguncei a sintaxe ao convertê-lo do código do produto. Aqui está um resumo do que eu estava tentando descrever. Talvez mais um problema com as definições de sublinhado. Mas se uma biblioteca de terceiros está causando problemas com o compilador ts, não deveríamos ser capazes de ignorar essa linha de código?

+1. Isso será útil para teste, pois preciso ter certeza de que meu código emita um erro quando for passado em algo que não era esperado.

Este recurso útil seria apenas a generalização de ! para objetos possivelmente nulos.

Se eu quiser trazer um arquivo de biblioteca para um projeto (por exemplo, Chartjs), costumo salvá-lo como um arquivo TS (gosto de manter todos os arquivos de origem como TS e compilados como JS) e importá-lo com uma barra tripla ref para o TS arquivo que requer isso. No entanto, o TypeScript então reclama incessantemente sobre erros naquele arquivo (naturalmente, pois é apenas um arquivo JS padrão salvo como TS).

No entanto, a capacidade de adicionar:

/*ts-errors-disable*/ ao início do arquivo de biblioteca e /*ts-errors-enable*/ ao final reduziria a saída de erros que não são relevantes, mas ainda permitem que os desenvolvedores mantenham todos os arquivos fonte como TS.

Ou devo apenas estar fazendo as coisas de maneira fundamentalmente diferente?

@benfrain Bem, seria melhor instalar o arquivo de definições do TypeScript correspondente, se ele existir ( npm install --save-dev @types/mylibrary ) ou criar seu próprio arquivo _.d.ts_ com um tipo any no namespace de sua biblioteca / classe principal primeiro:

// mylibrary.d.ts
declare module "mylibrary" {
    let mylibrary: any;
    export = mylibrary;
}

// main.ts
import mylibrary = require("mylibrary");
...

Eu tenho uma pergunta. Primeiro, o código e o erro que o TypeScript está destacando:

import {Directive, ElementRef, Input, OnChanges, SimpleChange} from '@angular/core'

@Directive({
  selector: '[blankAttr]',
})
export class BlankAttr implements OnChanges {
  @Input('blankAttr') private attrName: string // <--- TS Error: unused variable

  constructor(private el: ElementRef) {}

  public ngOnChanges(changes: {[key: string]: SimpleChange}): void {
    const change: any = changes.attrName 
    const prevValue: any = change.previousValue

    if (prevValue) {
      this.el.nativeElement.removeAttribute(prevValue)
    }
    this.el.nativeElement.setAttribute(change.currentValue, '')
  }
}

O problema que tenho é que preciso declarar o decorador @Input para permitir que uma string seja passada ao atributo. Mas eu só me importo com o valor dessa string quando ela muda. E posso obter o valor anterior e atual ao lidar com o evento de alteração.

Podemos ter // ts-ignore agora? Ou existe outra maneira de resolver isso bem?

@uglow, por que attrName privado? Esta é uma variável que Angular modifica para que você possa obter um valor com ela. Portanto, ele precisa ser público.

@ jmlopez-rod Eu mudei para público, mas isso não muda o problema. TS está dizendo que é uma variável não utilizada.

Estou usando o TS 2.4.1, depois de torná-lo público a digitação para de emitir o erro.

Antes:

Depois de:

Estou usando 2.3.3. Vou tentar o 2.4.1. Obrigada 😊

Isso deve ser incluído. Estou trabalhando com um mecanismo js personalizado que permite que um único arquivo .js retorne um valor. Veja minha essência para um exemplo . Eu uso o TS para gerar meus arquivos .js e é claro que o TS não sabe disso e lança:

A 'return' statement can only be used within a function body.

Uma nova pergunta SO que precisa suprimir o erro noUnusedLocals :
https://stackoverflow.com/questions/45519476/is-it-a-typescript-antipattern-to-dynamically-call-a-member-function-stored-in-a

@mhegazy Já enfrentei esse tipo de problema de várias maneiras diferentes.

Minha situação atual (todo o fluxo assume o modo de declaração):

• decoradores de classe exigem uma declaração de classe (não expressão de classe) e estou dentro de uma função - em princípio, isso poderia ser corrigido, mas não é hoje.
• ok, sem problemas farei a expressão uma declaração
• sem dados, a declaração agora tem um nome não utilizado
• ok, sem problemas vou devolver
• sem dados, Return type of public method from exported class has or is using private name
• ...?

Basicamente, a causa raiz aqui é que as expressões não podem ser decoradas, mas não é razoável abandonar tudo para implementar essa funcionalidade. Nesse ínterim, é sensato simplesmente suprimir esse erro. Eu ficaria bem se suprimir um erro exigisse que eu localizasse o problema do TypeScript associado e dissesse algo como // TS-LIMITATION:#9448 embora eu suspeite que isso resultaria em uma grande quantidade de novos problemas inúteis de sua perspectiva.

Eu até estaria bem se você adicionasse supressões direcionadas específicas para problemas conhecidos que você não está pronto para resolver ainda, mas apenas se isso fosse feito rapidamente e sem muito esforço de design (isso tornaria o mecanismo inútil: wink:)

Eu não quero obter um erro de código inacessível (onde fico feliz em anotar "cale a boca com erro de código inacessível aqui") quando faço algo como
if (false){ ...complicated debug code that I dont want to delete/forget... }

Portanto, o compilador TypeScript ainda não tem a opção de "calar a boca e não bagunçar outras ferramentas". Seria muito útil para nós ter essa opção por meio de comentários e por meio de opções de compilador para arquivos específicos ou até mesmo glob. Estamos presos ao uso de versões antigas de ferramentas porque não queremos perder o recarregamento automático (as versões mais recentes não recarregam automaticamente quando há erros). Então, ou desativamos a opção com erros noImplicitAny (o que eu realmente não quero, estou usando o TypeScript por causa da verificação de tipos e com a permissão implícita de qualquer TypeScript não traz muito para a mesa) ou permanecemos nas versões antigas dos pacotes. Sim, eu reportou o bug em ambos, Webpack e AwesomeTypeScript carregador, mas ninguém se importa. O problema está sendo ignorado há muitos meses. Vejo que é exatamente o mesmo com o pacote TypeScript :-(.

@polyglotinc if (!!false) {

@RyanCavanaugh Bem, por (!true) funciona ... Eu nem sequer pensei nisso como possibilidades porque eu _ (como um ex-compilador-escritor) _ dei ao compilador mais crédito em relação a constante / literal expressão entrando em colapso ... Eu acho que percebi que se fosse algo agitado sobre if (false) , saberia que if (!true) era a mesma coisa!

@unional, a questão do SO poderia ser escrita um pouco mais clara e talvez seja por isso que precisamos que o compilador nos informe sobre possíveis erros. Veja esta captura de tela mostrando o erro que o usuário deseja suprimir

Observe que na imagem eu só tenho um erro. Isso porque eu já consertei um problema detectado pelo compilador.

private keyHandlers = {
    'ArrowDown': function ($event: any) {
      this.handleArrowDown($event);
    },
    'ArrowUp': ($event: any) => {
      this.handleArrowUp($event);
    },
  };

O usuário afirma que handleArrow* estão sendo usados, mas o texto digitado não o vê sendo usado. No que diz respeito ao texto datilografado, this em this.handleArrowDown($event); pode ser qualquer objeto que tenha o método handleArrowDown . Com a função de seta, ele agora sabe que this é a instância da classe e, portanto, ele vê handleArrowUp sendo usado.

Outra opção: use o primeiro parâmetro falso this .

  private keyHandlers = {
    'ArrowDown': function (this: SomeComponent, $event: any) {
      this.handleArrowDown($event);
    },
    'ArrowUp': ($event: any) => {
      this.handleArrowUp($event);
    },
  };

@ jmlopez-rod Obrigado. Estas são boas alternativas. Gosto especialmente da solução function(this: SomeComponent, ...) {...} porque é a mais flexível.

A função de seta não funciona se keyHandlers não fizer parte da classe:

const keyHandlers = {
  'ArrowDown': function (this: SomeComponent, $event) {
    this.handleArrowDown($event); // error on accessing private method, filing an issue for it.
  },

  'ArrowUp': ($event) => { // doesn't work, duh
    this.handleArrowUp($event);
  }
}

export class SomeComponent {
  onKeyDown($event) {
    if (typeof keyHandlers[$event.code] === 'function') {
      keyHandlers[$event.code]($event);
    }
  }
  private handleArrowDown(_event) {
    // ...
  }

  private handleArrowUp(_event) {
    // ...
  }
}

Por outro lado, a função de seta é a mais direta neste contexto.

Estou tentando definir manualmente window.console para o IE9 para evitar erros no uso de console.log :

if (!window.console)
    window.console = {};

Mas eu obtenho error TS2540: Cannot assign to 'console' because it is a constant or a read-only property. Existe alguma solução alternativa para esses casos de uso?

@amiraliakbari Você pode declarar window como any tipo, o que efetivamente permite que você desative as verificações de tipo:

(window as any).console = {};

isso funcionou para mim substituir / desabilitar console.log globalmente - Observe que Project.logging foi definido antes disso

(window.console as any).___real_log = window.console.log;
window.console.log = function(args) {
  if (Project.logging) return (window.console as any).___real_log(args);
  return;
};

Isso também foi muito mais limpo do que colocar instruções if todo o meu código, pois posso usar console.log normalmente

Conforme mencionado em # 19109, ainda não temos a capacidade de suprimir um erro específico .

Conforme mencionado em # 19109, ainda não temos a capacidade de suprimir um erro específico.

Acho que o cenário básico descrito nesta edição foi abordado. podemos criar um novo problema para rastrear a supressão global de erros usando o número do erro. Temos relutado em usar códigos de erro dessa forma porque não têm expressividade.

Criado em # 19139.

Esta instrução funciona apenas por arquivo, certo? É possível fazer funcionar na pasta?

A instrução deve funcionar para uma única linha de cada vez. Se estiver vendo muitos erros de compilador em seu projeto, você pode verificar se deve ter opções de compilador menos restritas, como deixar noImplicitAny desativado (ou seja, as variáveis ​​são implicitamente any se não anotado). Você também pode deixar alguns arquivos como JS e definir allowJs mas checkJs desativado.

Por que você fechou este problema? A solução ainda está faltando! Por que você tem discussões sem sentido por 2 anos em vez de integração, uma possibilidade adequada de supressão de erros?

@ webia1 Você pode se interessar pelo # 19139, que ainda está aberto.

(Adicionar este comentário aqui, pois pode ser útil para aqueles que se deparam com esse problema, como eu fiz)

Encontrei https://github.com/Microsoft/TypeScript/pull/21602 e pode ser a solução.

Basta adicionar // @ts-ignore ao seu código (ou mesmo // @ts-ignore <some code error> para ignorar apenas o erro especificado) .

Testei aqui com TypeScript 2.7.2 e funciona!

(ou mesmo // @ ts-ignorepara ignorar apenas o erro especificado).

21602 não foi mesclado. Você não pode ignorar apenas alguns erros.

@RyanCavanaugh você está certo! Eu atualizei meu comentário. Obrigado!

Cheguei aqui procurando suprimir o erro TS2339.

document.getElementById('theme-admin').disabled = false; /* tslint:disable */
document.getElementById('theme-member').disabled = true; /* tslint:disable */