preciso disso rs

O caso de uso atual para esse recurso é um teste de unidade que lida com espaços em branco. Temos a regra "no-trailing-whitespace" ativada em nossa base de código por um bom motivo, mas não poder dominá-la em um nível de bloco significa que não podemos testar facilmente espaços em branco à direita e retornos de carro usando uma string de modelo ES6 .

um dos meus casos de uso para usar o pacote personalizado _ a.k.a partial import _ em mathjs

// tslint:disable:no-var-requires
import core from 'mathjs/core'

// @ts-ignore
import mathUnit from 'mathjs/lib/type/unit'
// @ts-ignore
import mathExpression from 'mathjs/lib/expression/function'
// @ts-ignore
import mathArithmatic from 'mathjs/lib/function/arithmetic'


const math = core.create()
// math.import(require('mathjs/lib/type/unit'))
// math.import(require('mathjs/lib/expression/function')) // compile, eval
// math.import(require('mathjs/lib/function/arithmetic')) // basic arithmetic like divide, exponent, etc

math.import(mathUnit)
math.import(mathExpression) // compile, eval
math.import(mathArithmatic) // basic arithmetic like divide, exponent, etc

export const unit = math.unit
export const createUnit = math.createUnit
export const compile = math.compile

Eu gostaria de ignorar erros para um arquivo inteiro. Eu herdei um código ES6 JS que gostaria de transpilar para ES5, mas tenho que usar o Babel no momento. Seria bom apenas renomear o arquivo para .ts e transpilar com TS.

@ptallett você pode apenas compilar arquivos .js usando allowJs e incluindo-os na compilação. Por padrão, não emitimos erros em arquivos .js , a menos que o arquivo tenha um comentário // @ts-check na parte superior ou você ative checkJs .

Eu ainda adoraria essa funcionalidade, estou sentado em um arquivo de teste, ele tem a extensão .ts, para que eu possa importar e ver facilmente quais parâmetros vão para onde, e compilá-lo para um diretório ao lado dos arquivos src é brilhante para o meu caso de uso .

A maioria das minhas linhas agora está vermelha, pois propositadamente tento excluir alguns parâmetros, ou dar um tipo diferente para a função, do que originalmente leva, e espero um erro lançado, pois também o procuro em tempo de execução.

Seria ótimo não ter um monte de linhas vermelhas em todos os lugares. :)

Existe alguma atualização sobre ele, ou alguém encontrou alguma boa maneira de fazer isso?

Usar lodash e especialmente lodash/fp com TypeScript é muito doloroso, e mesmo com as versões mais recentes de lodash & @types/lodash você pode acabar com mensagens de erro muito enigmáticas.

Se pudermos ter um @ts-ignore-block que ignore erros para o bloco a seguir, seria ótimo para casos de uso como este em que _você sabe o que está fazendo_ :-)

Estou trabalhando com código legado com inúmeras variáveis ​​de escopo global e escrever @ts-ignore em cada linha se torna tedioso, alguma atualização sobre isso?

Também buscando uma atualização sobre este pedido. Obrigado!

Isso também seria muito importante para o que estou fazendo (ou seja, verificar as funções de renderização do modelo Vue geradas pela verificação de tipos, o que exigiria desabilitar inspeções específicas para um bloco de código).
Junto com esse problema, #19139 seria muito importante, porque especialmente ao aplicar a grandes partes do código, você só deseja desabilitar inspeções específicas.

com a supressão do arquivo hole, isso pode ser adicionado aos editores, como o código vs, para salvar nas configurações do espaço de trabalho ou algo assim.

Também precisa disso. Estou gerando automaticamente um arquivo ts inteiro com tipos para meu esquema GraphQL usando graphql-code-generator e há uma importação estranha acionando noUnusedLocals.

/* tslint:desativar */

código

/* tslint:ativar */

// @ts-ignore-start
// @ts-ignore-end

Pode ser combinado com: https://github.com/Microsoft/TypeScript/issues/19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn isso não é tslint.

Às vezes, enquanto estou movendo coisas e refatorando, quero ignorar temporariamente o arquivo inteiro (ou seja, não compilá-lo), sem mexer nas opções da CLI.

O mais rápido/fácil é um sinalizador no topo do arquivo:

// @ts-ignore-file

@lonix1 Seu caso de uso é coberto por:

// @ts-ignore-start
// @ts-ignore-end

Você não precisa usar a parte // @ts-ignore-end . Muitas ferramentas de fiapos funcionam dessa maneira.

@mgol Não quero inviabilizar este tópico... mas tentei sua sugestão - obrigado! - e não funcionou para mim. Juntei as linhas na parte superior do arquivo e também tentei uma na parte superior e outra na parte inferior.
Alguém mais consegue fazer funcionar?

@lonix1 Eu quis dizer que a proposta de @Blanen também funcionaria para você, não precisamos do TypeScript para implementar // @ts-ignore-start + // @ts-ignore-end e // @ts-ignore-file , implementando // @ts-ignore-start + // @ts-ignore-end seria suficiente. Isso não foi implementado, é por isso que esse problema ainda está em aberto.

@DanielRosenwasser isso só funcionaria quando os arquivos ts fossem armazenados em outra pasta durante a compilação. quando o projeto é configurado para colocar os arquivos js ao lado dos arquivos ts, ele não vai. Também os arquivos js serão 'compilados', por exemplo, transformar para es5 ? Ao transportar código legado, isso seria realmente útil.

Precisa desse recurso.

Caso de uso:

O TypeORM espera que criemos classes de entidade de banco de dados que tenham colunas que podem ou não ser anuláveis. Muitas colunas (portanto) não são anuláveis... e, portanto, devem ser tratadas, exceto na definição de classe, como se as propriedades fossem incondicionalmente de certos tipos definidos. No entanto, o Typescript exige que definamos cada coluna como sendo fortemente tipada. Assim, acabamos com muitas entidades como:

@Entity('investigation')
export class InvestigationEntity {
    @PrimaryGeneratedColumn('uuid')
    // @ts-ignore TS2564
    public investigationId: string;

    @Column({ type: 'uuid' })
    // @ts-ignore TS2564
    public userId: string;

    @Column({ type: 'jsonb' })
    // @ts-ignore TS2564
    public metadata: IEncryptedJSONContainer;
}

Cada coluna é obrigatória e (portanto) certamente conterá um valor, mas devido à maneira como o TypeORM funciona, cada propriedade deve ser definida de forma que não tenha um inicializador. Seria extremamente conveniente poder suprimir esse problema específico, derivado/específico de ORM, para uma classe inteira (portanto/ou arquivo).

@haggholm algum motivo para preferir ts-ignore sobre public metadata!: IEncryptedJSONContainer ?

@RyanCavanaugh Ignorância! Eu tinha perdido esse recurso na documentação. Desculpe; por favor ignore.

eu gostaria de fazer

// @ts-ignore-start
--strick verificações nulas, para um arquivo específico

Isso é o que parece o teste unitário de campos privados e métodos com script datilografado. Eu tenho 6 linhas dedicadas a ignorar o código. Horrível. Faz meus olhos sangrarem. Quaisquer soluções alternativas para ignorar o bloco seriam muito apreciadas.

it('TestNode_ReconnectionsWorkload', async function () {
    for (let i = 0; i < 1; i++) {
        nodes.push(await Node.NewNode(serverUrl, {
            handlers: {
                active: async function (n: Node) {
                    try {
                        // @ts-ignore
                        if (n.view.Empty()) {
                            // @ts-ignore
                            if (n.conns.Empty() && !n.server) {
                                // @ts-ignore
                                await n.login(n.address);
                            }
                            return;
                        }

                        const data = new flats.Message({
                            // @ts-ignore
                            id: n.id,
                            type: flats.MessageType.Data,
                            data: 'hello world',
                        });

                        const dataBytes = data.toBytes();
                        const dataBase64 = base64.encode(dataBytes);
                        // @ts-ignore
                        const dataSigBytes = await n.sign(dataBytes);
                        const dataSigBase64 = base64.encode(dataSigBytes);

                        // @ts-ignore
                        for (const conn of n.conns.Iter()) {
                            conn.Send(`${dataBase64}.${dataSigBase64}`);
                        }
                    } catch (error) {
                        console.log(error);
                    }
                },
            },
        }));
    }

    for (const node of nodes) {
        await node.Wait();
    }
});

Bem, eu estava prestes a adicionar um novo problema, mas acho que esse problema o cobre.

@ts-ignore lida com importações de várias linhas e de uma única linha!

Ainda existem muitos módulos npm que não possuem tipagens, ou são escritos sem NoImplicitAny,
que resultam em erro "qualquer implícito", então eles são importados:

import { a, b } from 'MyNonTypedModule' // <-- Implicit any error

Então eu posso usar @ts-ignore:

//@ts-ignore
import { a, b } from 'MyNonTypedModule'

Mas quando trabalho com importação automática e formatadores como o Prettier isso acontece:
(Formatado por Prettier)

//@ts-ignore
import { 
  a, 
  b 
} from 'MyNonTypedModule' // <-- Still (again) getting the Implicit any error

Eu posso corrigi-lo com:

import { 
 a, 
 b
//@ts-ignore
 } from 'MyNonTypedModule'

ou

//@ts-ignore-start
import { 
   a, 
   b
} from 'MyNonTypedModule'
//@ts-ignore-end

Mas então começa a ficar assim em importações de linha única:

//@ts-ignore-start
import { a } from 'MyNonTypedModule'
//@ts-ignore-end
import { b } from 'SomeTypedModule'
//@ts-ignore-start
import { c } from 'SomeOtherNonTypedModule'
//@ts-ignore-end

Então eu tenho que escrever assim porque a importação automática e a formatação mudarão entre importação de linha única e de várias linhas dependendo de quantos elementos são importados do módulo.
Realmente anula o propósito da importação automática se eu alterar o código de importação manualmente.

Seria bom não ter que escrever ts-ignore-start e ts-ignore-end em todas as importações,
Então: //@ts-ignore para a importação (não apenas a próxima linha) é, na minha opinião, algo que ts-ignore deve manipular. (Ou algum outro ignore como: @ts-ignore-block / @ts-ignore-import )

eu preciso suprimir certos erros em todo o arquivo:

// @ts-ignore-all TS1206

/*
... rest of the file
*/

De acordo com as pessoas acima que sugeriram comentários // @ts-ignore-start e // @ts-ignore-end para lidar com os casos de uso mencionados neste tópico.

Isso é legal, porque se parece muito com a diretiva // @ts-ignore atual, e permite que você ignore todos os erros em um arquivo com apenas a diretiva // @ts-ignore-start no topo.

Existem casos de uso positivos para várias das sugestões acima. Eu proponho:

@ts-ignore como comportamento presente
@ts-ignore TSxxx [TSxxx ...] suprimir erros específicos
@ts-ignore-start bloco inicial para ignorar
@ts-ignore-start TSxxx [TSxxx ...] suprimir erro(s) específico(s) para bloco
bloco final @ts-ignore-end
@ts-ignore-all suprimir erros para o resto do arquivo
@ts-ignore-all TSxxx [TSxxx ...] suprimir erros específicos para o resto do arquivo

"Erros específicos" podem incluir grupos nomeados semelhantes aos do tsconfig ou grupos definidos pelo usuário de erros TSxxx.

Não tenho certeza sobre o valor de ignorar blocos aninhando módulos importados; minha preferência seria blocos ts-ignore explícitos em arquivos de módulo importados. Mas ao importar libs de terceiros, pode haver razões para isso, então estou em cima do muro aqui.

o arquivo .tsignore desejado

como .npmignore e .gitignore

Deve haver bloco de ignorar. Eu fiquei preso com o quadro de marionetes. No manipulador de marionetes, você tem o método "avaliar" que permite executar blocos de script arbitrários em uma página. Este bloco de script arbitrário pode conter referência a funções que estão disponíveis na página, em outras palavras, a referência de função estaria disponível em tempo de execução.

// @ts-ignore-start
// @ts-ignore-end

Isso será extremamente útil ao trabalhar com pedaços de código legado, tornando menos doloroso para as pessoas mudar para o TypeScript.

Sobre

// @ts-ignore-start
// @ts-ignore-end

Eu fiz essa sugestão anteriormente e meio que quero mudar a sintaxe.
Ou faça começar-parar ou começar-terminar
start e end (como verbos) não são antônimos e isso me incomodaria para sempre se fosse digitado.

Isso é legal comigo

// @ts-ignore-begin
// @ts-ignore-end

Funcionalidade altamente necessária.

Por que isso ainda não é possível? :-(

Eu preciso bloquear ignorar também

+1

+1

alguma atualização disso?

🙏🏻

E se fizermos da mesma forma que normalmente fazemos com eslint?

/* @ts-disable */

!function(){
  // no ts here!
}()

/* @ts-enable */

Como mencionado acima: Assim que você estiver gerando código TS (por exemplo, com swagger) onde, por exemplo, vars não utilizados podem ocorrer, você precisa desse recurso.

+1

Sem //@ts-ignore-file é impossível migrar para o TS

Então, é sem ninguém perceber não é verdade

@RyanCavanaugh A comunidade claramente precisa disso, existe uma razão para isso não ter sido abordado? Obrigado!

Estou lutando com isso agora, pois não posso nem brincar com a obtenção de uma solução que funcione para ver se é viável sem o Typescript chorando e bloqueando minha renderização.

No momento, estamos precisando desse recurso.

Estamos importando uma biblioteca pública que tem tipos Node para algumas funções que não nos interessam. Portanto, seria bom usar // @ts-ignore para uma única importação, em vez de usar skipLibCheck para ignorar todas as libs.

Inicialmente eu gostei // @ts-ignore-file idea, mas // @ts-ignore provavelmente funcionaria melhor por uma questão de consistência.

Então... abri o #33383 com suporte para //@ts-nocheck em arquivos datilografados. Agora, nós sendo a equipe do compilador _TypeScript_, nós realmente não entendemos (não corrigindo problemas prováveis, o que !!?!?) - mesmo //@ts-ignore em texto datilografado só se tornou uma coisa porque nosso braço estava torcido um pouco, então estamos... hesitantes... em adicionar mais mecanismos de supressão. Então, se vocês realmente sentem que um mecanismo de supressão tão amplo é necessário, seria bom se vocês pudessem ir até lá e 👍

@weswigham , Embora este provavelmente não seja o mais importante dos recursos. Pode ser útil durante o desenvolvimento. Assim como comentar temporariamente algumas linhas de código, pode ser útil ao desenvolver e tentar isolar um problema em outro lugar. No entanto, gostaria de receber um aviso para que essa prática não encontre uma maneira de realmente causar erros de tempo de execução. Talvez até habilite esse recurso apenas para desenvolvimento, mas para lançar um erro na compilação.

Como esse problema ainda está rotulado como "Aguardando mais comentários", veja mais:

Ao prototipar rapidamente novas direções arquitetônicas, gostaria de fazê-lo guiado pelo TypeScript, para garantir que a nova arquitetura funcione. No entanto, quero ignorar temporariamente os erros de tipo nos arquivos de teste de unidade , apenas temporariamente, enquanto experimento.

Adicionar algum tipo de comentário @ts-ignore- no topo de cada arquivo seria bastante fácil.

Eu sugiro a necessidade do @kumar303 : no teste de unidade, é benéfico desativar alguma verificação para esse determinado bloco/arquivo, pois serão as asserções que cobrirão esses casos.

@weswigham Você pode colocá-lo atrás de um sinalizador do compilador.

Você pode colocá-lo atrás de um sinalizador do compilador.

Não há necessidade - está na versão 3.7 beta.

re: https://github.com/microsoft/TypeScript/pull/33383 : @weswigham isso é ótimo, obrigado! Um caso de uso poderoso aqui é ignorar temporariamente a verificação de tipo em um arquivo, então sugiro também enviar uma regra de lint que falha quando se esquece de remover @ts-nocheck

Tendo um problema no gatsby, onde uma consulta graphQL estática funciona em arquivos .jsx , mas não em arquivos .tsx . Acho que essa proposta poderia ser uma solução mais aceitável. (edição aqui https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5)

Ei!
A solução proposta foi implementada?

// @ts-ignore-start
// @ts-ignore-end

Acho que seria muito benéfico. Eu não me importaria de trabalhar nisso.

Adicionamos suporte para //@ts-nocheck para suprimir todos os erros em um arquivo inteiro na versão 3.7. Acho que a supressão de nível de linha e nível de arquivo pode abranger _most_ necessidades sem muito barulho. Se você tiver um bloco suficientemente grande dentro de um arquivo verificado que deve ser desmarcado, talvez apenas desative a verificação de todo o arquivo ou, se isso for desagradável, extraia o pedaço não verificado para seu próprio arquivo e desative a verificação desse arquivo ou, na falta disso, suprimir cada linha com um problema real? Um ts-ignore deve ignorar um único problema, enquanto um ts-nocheck deve ignorar um único arquivo - uma supressão baseada em intervalo não mapeia para uma unidade específica de forma alguma, então parece de alguma forma pior (já que não pode ser mapeado para um único problema ou causa raiz que você está suprimindo). Pelo menos sem supressões específicas de código de erro, não estou particularmente confortável com supressões baseadas em intervalo.

Eu, pelo menos, preferiria uma única supressão ( //@ts-nocheck File is a legacy untyped UMD module concatenated into the build - declarations are pulled from node_modules, so errors here are hopefully meaningless ) no topo do arquivo ou supressões individuais ( //@ts-ignore The TS compiler doesn't support the assignment on the next line because we never declare it, but we provide this for legacy compat ) em cada coisa ruim individual (tm). Não posso, pela minha vida, apresentar um exemplo convincente e baseado em princípios em que _intervalos_ específicos de código devem ser desmarcados (ao contrário de arquivos, que tinham um raciocínio claro de estratégia de migração), além de "escrever vários arquivos consecutivos supressões fazem meus olhos sangrarem", pelo qual tenho _zero_ simpatia, pois, fundamentalmente, acreditamos que você não deveria usar supressões no TypeScript. Se for um problema de tipo, você pode expulsá-lo (é por isso que existem declarações de módulo any , conversão e abreviação). Se for um problema de sintaxe, tudo é horrível e estaremos quebrados de qualquer maneira, então as supressões não farão nada (supressões não afetam os erros de análise).

Obrigado por //@ts-nocheck , mas isso não resolve o problema de desabilitar a verificação de bloco de código:

const $element = document.createElement('iframe')
$element.loading = 'lazy' // Property 'loading' does not exist on type 'HTMLIFrameElement'.

// @ts-nocheck

Eu tenho um caso de uso interessante.

Construímos ou possuímos ORM em Typescript que usa acorn para compilar instruções em nosso DDL.

Para fazer uma consulta where, temos que passar variáveis ​​com escopo:

.entities
.include('parent')
.where(m => m.id === this.id, { id: this.entityId })
.toList()

Isso não funciona simplesmente porque: Property 'id' does not exist on type 'xxx'

Se eu envolvê-lo em @ts-ignore-start funcionará bem assim:

// @ts-ignore-start
.where(m => m.id === this.id, { id: this.entityId })
// @ts-ignore-end

Mas quando o formatado aparece e começa a adicionar quebras de linha:

// @ts-ignore-start
.where(m => m.id === this.id || m.id === this.id2, {
  id: this.entityId,
  id2: this.entity2Id
})
// @ts-ignore-end

Não funciona mais.

Isso não funciona simplesmente porque:

Esse é exatamente o tipo de erro de nível de tipo para o qual você deve apenas ter um as any cast (ou, em jsdoc, /** <strong i="8">@type</strong> {any} */(expr) ) no(s) acesso(s), se você realmente deseja suprimi-lo.

//@ts-nocheck não funciona para o meu projeto angular ts, mas //@ts-ignore sim. Este problema para a microsoft começou em 2017. 2017! Uau...

3 anos e nenhuma solução. Não é de surpreender que os desenvolvedores de JavaScript não queiram pular para o texto datilografado

// @ts-ignore-start
// @ts-ignore-end

Pode ser combinado com: #19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn isso não é tslint.

Algum plano para implementar isso?

// @ts-nocheck
é a única opção atualmente :(

Outro caso de uso a ser adicionado para consideração aqui ...

Estou gerando um monte de código TypeScript a partir de uma linguagem de marcação interna que permite algum fluxo de controle básico e condicionais. Enquanto eu controlo o comportamento de geração de código, eu não controlo as entradas passadas para o gerador de código (que depende dos usuários finais)

Como resultado, o código gerado pode facilmente ter código inacessível ou, em um caso, TS2367, pois pode haver código aninhado que testa um valor em relação a uma constante enum, então dentro desse bloco contém outra verificação dessa variável em relação a outra constante enum. Por exemplo:

if (foo === MyEnum.ONE) {
  const bar = (foo === MyEnum.TWO ? "two" : "one");
}

Com código escrito à mão, esse padrão é fácil de corrigir e evitar. Com a geração de código, no entanto, cabe aos meus usuários (desenvolvedores, você conhece o tipo!) não fornecer entradas que testem desnecessariamente valores impossíveis.

Não desejo desabilitar totalmente a verificação de tipos, mas não tenho outro mecanismo para consumir o código gerado pelo código devido a esse erro. Idealmente, eu suprimiria esse erro para todos os arquivos gerados por código, mas manteria todas as outras verificações de tipo.

Como está, não tenho outra solução além de desativar toda a verificação de tipos. Nesse ponto, não estou obtendo muito valor do TypeScript versus JavaScript simples

Você está falando sério? Isso ainda é um problema em aberto e não implementado no TS4? 🤦🏽

@ivnnv Você pode usar // @ts-expect-error no TS 3.9, veja aqui

@ndraiman @ts-expect-error funciona para linhas individuais, mas não para blocos , então ainda é necessário colocar muitos deles se alguém quiser "ignorar um bloco"

Aqui estão mais alguns comentários para você:

O que mais você precisa? O que a comunidade precisa fazer para obter essa funcionalidade?

O melhor caso de uso para isso é a alternativa de escrever any em cada tipo que está sendo feito. Você pode não ter simpatia pela estética (que sem dúvida tem impacto no humor e na produtividade), mas apenas ter uma alternativa que corresponda às expectativas comuns não deve ser difícil de aceitar.

As pessoas têm opiniões diferentes sobre o que é aceitável e o que não é.

Para algumas pessoas, é muito demorado e limita o estado de fluxo em que as pessoas podem estar enquanto fazem coisas mundanas, como portar código.
Eu acho chato e estranho que eu não possa ter um bloco de código ignorado, mas em vez disso ter que enchê-lo com conversões any , o que geralmente tem um efeito prejudicial na legibilidade (até que os tipos apropriados estejam lá). Ter que escrever continuamente um novo comentário ou ceder a uma distração _só porque alguém não vê o benefício de ignorar blocos de código_ não é bom na minha perspectiva.

EXEMPLO:

Um é portar um projeto de JS para TS, com o outro projeto sendo desenvolvido por terceiros.

A sintaxe e as regras seguidas no projeto portado podem ser antigas, por exemplo, es2015, ou obsoletas em favor de uma sintaxe mais clara e menos código, etc.

Ao portar este projeto, parte do código pode ser extremamente fácil de portar para o TypeScript. Ainda assim, inevitavelmente se depara, por exemplo, com booleanos e funções com comportamento arbitrário, por exemplo, que precisam de mais contexto ou precisam ser pensados ​​por algum tempo para criar seus tipos.

Seria tão incrível parar de verificar uma função ou um bloco de código em um arquivo enquanto o conserta. Ignorar um bloco de código permitiria que alguém se movesse rapidamente nas áreas que conhece e com as quais se sente confortável e salva certas partes para mais tarde.

Meu fluxo de trabalho quando preciso portar JavaScript para TypeScript (e o código é, bem, abaixo da média):

1. Copie o código do arquivo .js para o arquivo .ts.
2. Veja se o TS pode inferir quaisquer tipos por uso
3. Compreender manualmente os tipos de uso
4. Perceba que os erros são a maldição da minha existência
5. Tente comentar os erros, melhorando assim o número de linhas no arquivo às vezes x3 ESLlint + TS (mais é melhor?)
6. Remova e adicione // @ts-check no topo enquanto edita cuidadosamente o restante dos arquivos e adiciona mais tipos.

Se pudéssemos ignorar os blocos:

1. Copie o código de .js para .ts
2. Veja se o TS pode inferir quaisquer tipos por uso
3. Compreender manualmente os tipos de uso
4. // @ts-ignore-enable ... // @ts-ignore-disable funções individuais e blocos de código problemáticos
5. Descomente os blocos à medida que os chego e adiciono tipos

Decida por si mesmo o que parece mais razoável. É o mesmo ao portar JS para um projeto com muito mais regras ESLint, e você precisa refatorar a maioria das coisas.

Eu gostaria que pudéssemos fazer como é possível no ESLint e usar /* eslint:disable */ ... /* eslint:enable */ no TypeScript.

PS Acabei de perceber ao verificar este comentário que passei mais de 20 minutos tentando obter uma experiência que eu (e muitos outros) buscamos desde 2017, apenas para comentar sobre uma questão aberta de 3 anos.

@weswigham @RyanCavanaugh

Lembrete :+1:

Dará primogênito em troca disso

@agusterodin Seu sacrifício atrai a atenção dos males.....

Tudo bem, nada acontece de fato, exceto que eu apenas dou um simples PR :)

No entanto, pessoalmente, concordo totalmente com a opinião da equipe TS - esta função é ruim, você deve sempre tentar evitar usar @ts-ignore , não usar @ts-ignore-enable (ou @ts-ignore-start , qualquer que seja).
Mas às vezes, você sabe, o provérbio diz drinking posion to satisfie thirst , eu sei que é uma má escolha, mas é apenas uma necessidade.

edit: adicione explicação e exemplos.
Este PR adiciona duas diretivas ts-ignore-enable e ts-ignore-disable .

1. se usar apenas ts-ignore-enable, a parte restante será ignorada.

...   <-- this is normal
// @ts-ignore-enable
XXX    <-- this is ignored
...    <-- this is ignored

1. você pode adicionar as mesmas diretivas várias vezes, mas elas funcionam apenas uma vez.

// @ts-ignore-enable
XXX  <-- this is ignored  
// @ts-ignore-enable       <-- you could remove this line.
YYY   <-- this is ignored
// @ts-ignore-disable
ZZZ   <-- this is normal
// @ts-ignore-disable      <-- you could remove this line.

1. // @ts-ignore-disable poderia ser usado sozinho, nada aconteceria.

2. @ts-expect-error não funcionaria na região ignorada

// @ts-ignore-enable
XXX  <-- this is ignored
// @ts-expect-error       <-- No error message. whatever next line has error or not.
YYY   <-- this is ignored

1. sem rótulo de região, são apenas comentários.

// @ts-ignore-enable A
XXX  <-- this is ignored  
// @ts-ignore-enable   B    <-- you could remove this line.
YYY   <-- this is ignored 
// @ts-ignore-disable B
ZZZ   <-- this is normal
// @ts-ignore-disable A     <-- you could remove this line.

Em um mundo perfeito, não precisaríamos ignorar a segurança de tipo, certo? :sweat_smile:
Eu preciso disso ao copiar um trabalho fantástico, por exemplo, exemplos e iniciantes, até mesmo a resposta SO ocasional que não é digitada ou digitada como eu gostaria. Principalmente para tê-lo no meu código de segurança de tipo que segue minhas configurações. Eu apenas uso configurações muito rígidas e muitas vezes tenho que reescrever uma função ou alguma lógica por causa disso. Não é porque eu quero continuar ignorando aquele bloco de código, isso não faria sentido.

Ignorar um bloco de código é uma conveniência, que para mim parece perfeitamente razoável, dado o fato de que ainda posso @ts-ignore cada linha em um bloco.

Eu entendo as possíveis implicações que isso pode ter para as pessoas que vão I'll just ignore this because it's easier . A meu ver, quem poderia usar block scope ignora drink poison to satisfy their thirst já está bebendo gotas de veneno com @ts-ignore .

Agora que você pode fazer @ts-nocheck em arquivos .ts , sugiro permitir @ts-check em arquivos .ts para que possamos desligar/ligar o verificador de tipos:

import fs from 'fs'

fs.readFileSync(32423) // type checking

// @ts-nocheck
fs.foobarbaz() // type checking is off
fs.__randomThing()

// @ts-check
fs.readFileSync(123) // now type checking again

Isso não requer a definição do que é um "bloco de código". Você pode iniciar e parar a verificação de tipo de - para qualquer linha.

ATUALIZAÇÃO Eu estava enganado, consulte https://github.com/microsoft/TypeScript/pull/40267#issuecomment -713840095 para a correção.

Ao tentar migrar um aplicativo usando styled-components para o TypeScript, encontrei um problema em que @ts-ignore não pode ser usado acima das strings de modelo (por algum motivo). Poderia ter sido resolvido com um bloco de ignorar.

Exemplo do erro TS que eu estava tentando ignorar:

import styled from "styled-components";
import { Button } from "...";

// @ts-ignore here does not work
const StyledNavBar = styled.div`
  ${Button} {
    margin: auto 0;
  }
`;

Como uma nota extra: não posso converter nenhum no meu projeto TS, não permito nenhum tipo. Qual é a recomendação então?

@weswigham Quais são seus pensamentos sobre estado de fluxo e produtividade no contexto da estética? Parece que você não tem nenhuma simpatia por olhos sangrando; mas você tem alguma noção sobre produtividade, portabilidade de código e os processos que descrevi? Você ainda não vê nenhum benefício _de todo_, depois de considerar meu comentário, e no contexto de ser mais produtivo? Também descrevi algumas situações reais em que seria necessário ignorar o escopo do bloco. Além disso, como essa funcionalidade não se compara ao ESLint e à funcionalidade que esperamos lá?

Está cientificamente comprovado que menos interrupções aumentam a produtividade e aumentam a eficiência; ignorar o escopo do bloco permitiria menos interrupções ao portar o código. A equipe do TS não percebe que "fundamentalmente, acreditamos que você não deveria usar supressões no TypeScript de forma alguma". é uma opinião baseada na vida e na respiração do TypeScript, e que no mundo real, as pessoas precisam portar código mal escrito para outras bases de código, com mais segurança de tipo e outras regras de linting; nessas situações, não faz sentido ignorar um arquivo ou uma linha, mas não o bloco de código que você acabou de importar.

Para mim, parece que você está indo para a utopia enquanto ignora a realidade. @sandersn Você não abordou nenhum dos meus pontos e manteve a resposta antiga em discussões mais recentes no caso. Você também afirma que, a menos que a equipe decida de outra forma, não deve ser implementado, nesse caso: encerrar o problema?

A equipe precisa tomar uma decisão ou implementar um recurso claramente desejado.

Manter a questão no limbo não faz o menor sentido.

Lamento não poder lhe dar a finalidade que você precisa, mas a realidade é que "talvez mais tarde" é uma resposta com a qual você terá que aprender a conviver. Qualquer recurso não pode ser apressado no produto amanhã, e para recursos que se enquadram em nossos parâmetros de design, existem milhares de sugestões atualmente em aberto que estão competindo por nossa capacidade de adicioná-los ao produto de maneira ergonômica, útil, estável e com visão de futuro.

Priorizamos as coisas com base no feedback atual, no estado das soluções e soluções alternativas atuais, na preponderância desses cenários, nas ferramentas e em uma centena de outros fatores. Coisas que não são de alta prioridade agora podem se tornar de alta prioridade mais tarde. Essa é a natureza de "talvez mais tarde" e acho que é uma representação precisa de onde essa sugestão está. A decisão aqui, por enquanto, é continuar a monitorar o feedback e entender o que as pessoas estão encontrando que pode exigir que esse recurso seja de maior prioridade do que qualquer outro recurso que possamos adicionar a seguir, dos quais existem centenas competindo por atenção.

O tom aqui é honestamente tendendo ao hostil e falando pessoalmente, ser empurrado para um ultimato não conduz a uma conversa construtiva que nos ajude a entender onde isso está agregando valor que supera sua complexidade em relação às alternativas.

Lamento ter feito um ultimato. Fiquei bastante irritado ao ver atividade em relação ao PR, mas nenhuma sobre o assunto. Concordo que meu comentário anterior não contribui de forma construtiva.

Posso aceitar que esse problema pode precisar esperar. Forneci alguns comentários e perguntei quais outros comentários são necessários para chegar mais perto da resolução, mas não obtive resposta. Parece, por mais irritante que seja, que meu comentário pouco construtivo era o que eu precisava fazer para obter _alguma_ resposta da equipe.

Ainda parece que nenhuma progressão real em direção a um problema com mais de 700 reações positivas, que tem vários anos, foi feita. Não acredito que deva ser mais rápido, mas parece que a equipe está desinteressada em explorar esse recurso, já que os membros têm opiniões pessoais contra ele. Eu entendo completamente todas essas coisas. Não é sobre isso que estou falando aqui, no entanto. Quero conversar um pouco, mas estou sendo ignorado.

Eu gostaria de saber que meu feedback é considerado e, dada a sua natureza, respondido. Não é uma grande interrupção no conjunto de recursos, mostrado pelo PR ativo que foi ativado em um curto período de tempo. Tudo está pronto, as pessoas continuam reagindo positivamente para resolver esse problema com um recurso de ignorar o bloco, e eu perguntei o que a comunidade precisa fazer para obter esse recurso. Eu discordo fortemente de vários pontos da equipe e tenho argumentado contra isso, um PR foi feito e um comentário dado afirmando que 'a menos que mudemos de ideia' nada vai mudar.

É aí que minha frustração vem à tona. Você deseja desconsiderar um recurso pronto porque nenhuma alteração foi feita em relação a uma decisão de um membro da equipe, ignorando completamente o feedback meu e de outras pessoas.

Parece que, a menos que alguém da equipe decida de outra forma _de acordo com sua vontade_, não veremos nenhuma mudança nessa questão. Isso não exige mais feedback da comunidade, não é? Foi por isso que fiz o ultimato errado.

Eu fiz vários argumentos contra os pontos de @weswigham , dei alguns exemplos e honestamente ainda estou esperando algum tipo de resposta. A única coisa que parecia ajudar era estar visivelmente chateada e pouco construtiva.

Como nos movemos daqui? Qual feedback a equipe gostaria? Parece um problema pessoal escondido atrás de "Priorizamos as coisas com base no feedback atual, o estado das soluções e soluções alternativas atuais, a preponderância desses cenários, ferramentas e uma centena de outros fatores". já que várias pessoas tentaram dar feedback sem nenhuma resposta da equipe.

Gostaria de reiterar que entendo que isso pode não ser uma alta prioridade se tirarmos as opiniões das pessoas do assunto. Ao mesmo tempo, o recurso está pronto para ser implementado e os argumentos foram feitos. O que é necessário agora é que a equipe tome uma decisão/resposta (não necessariamente implemente nada) e a torne pública. Se não é isso que é necessário, por favor me diga o que é, ou como alguém poderia ajudar a aumentar a prioridade em _qualquer_ recurso ou problema para o TypeScript, mas especialmente este.

Outro caso de uso para multilinha ( @ts-ignore-start+@ts-ignore-end ) ou inline (como /* @ts-ignore */ ) @ts-ignore .
Meio Ambiente:

• "noUnusedParameters": true
• Regra ESLint require-jsdoc ativada.
• Código semelhante ao seguinte (exemplo simplificado):

type Data = Record<string, unknown>;
type PrepareSettings = Record<string, unknown>;

/**
 * This is base class that will be inherited.
 */
class SuperClass {
    /**
     * Prepare data for further usage.
     * 
     * <strong i="16">@param</strong> data
     *      Data that should be prepared.
     * <strong i="17">@param</strong> settings
     *      Operation settings.
     */
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {
        return data;
    }

    // Some additional methods...
}

Para a situação descrita, o TypeScript emite o seguinte aviso: 'settings' is declared but its value is never read.(6133) .
É possível suprimir o aviso adicionando @ts-ignore após o final do comentário da documentação:

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {

Mas depois disso, a ESLint reclamará de Missing JSDoc comment .
Então a solução é:

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {   // eslint-disable-line require-jsdoc

O que é estranho e feio.

@RyanCavanaugh @weswigham @sandersn

Um lembrete mensal de que isso é algo que a comunidade deseja discutir mais com a equipe do TypeScript. Há muito apoio e o que está faltando no momento é uma resposta da equipe. Entendo que há muita preponderância, e progredir no TypeScript não é tarefa fácil. As coisas levam tempo. Como não há resposta sobre como podemos aprofundar essa sugestão e tomar medidas mais diretas, farei um lembrete como este regularmente. Não vou desistir até que uma decisão seja tomada, e comentar parece afetar (principalmente quando sou um !@#).

Depois que esses anos se passaram, embora eu estivesse originalmente assustado como essa funcionalidade não existe, eu pessoalmente repensei um pouco ... Quando há um monte de @ts-ignore , você já pode dizer que há algo errado com seu código e passe algum tempo aprimorando seus tipos. Todos nós somos muito preguiçosos às vezes e queremos velocidade no geral, mas atualmente é mais fácil descobrir alguns tipos apropriados em vez de copiar e colar vários @ts-ignore em grandes quantidades de código. Se esse equilíbrio de INconveniência for quebrado, muitos de nós estaremos convenientemente abusando de @ts-ignore-enable, o que pode apenas diminuir a qualidade geral de todos os pequenos projetos de código aberto aqui e ali.

Aliás, embora vejamos que existem muitas reações 👍 sobre esse assunto, - pode ser tendencioso, porque muito mais pessoas podem se sentir completamente bem sem esse recurso enquanto ficam em silêncio, porque não estão aqui.

@JerryGreen Referenciando meus comentários mais antigos, eu disse exatamente a mesma coisa. Com a adição de que as pessoas já estão fazendo isso com o recurso de ignorar. Não há razão para implementar um pouco de veneno o tempo todo alegando que deveria haver _none_ .

Remova a funcionalidade @ts-ignore ou torne-a completa. Existem muitos argumentos para fazer isso, e as pessoas que escrevem código ruim continuarão usando @ts-ignore que é tão ruim quanto um recurso de ignorar bloco, eles são exatamente a mesma coisa - exceto que ignorar bloco é menos visualmente perturbador.

A comunidade ainda precisa de uma resposta da equipe TypeScript.

@JerryGreen Referenciando meus comentários mais antigos, eu disse exatamente a mesma coisa. Com a adição de que as pessoas já estão fazendo isso com o recurso de ignorar. Não há razão para implementar um pouco de veneno o tempo todo alegando que deveria haver _none_ .

Remova a funcionalidade @ts-ignore ou torne-a completa. Existem muitos argumentos para fazer isso, e as pessoas que escrevem código ruim continuarão usando @ts-ignore que é tão ruim quanto um recurso de ignorar bloco, eles são exatamente a mesma coisa - exceto que ignorar bloco é menos visualmente perturbador.

A comunidade ainda precisa de uma resposta da equipe TypeScript.

Alguns cenários especiais ainda precisam usar @ TS ignore. Por exemplo, a importação de CDN não depende de node_ The. O arquivo TS não existe no cenário de módulos

@L-Hknu Obrigado por esclarecer. As pessoas o usam como ignoram com o ESLint de qualquer maneira.

A funcionalidade de ignorar não é desabilitada em contextos além de onde é necessária para a funcionalidade. Isso me diz que não há problema em usá-lo para ignorar o código.

Ainda não consigo raciocinar por que não deve haver nenhum bloco de ignorar, pois ele é usado da mesma maneira na maioria das vezes.

Eu abandonei a conversão para tipos para alguns códigos-fonte abertos, porque o progresso da conversão teria sido muito mais confortável com as ignorações de bloco. Eu não preciso disso, mas acho que muitas pessoas vão colocar um pé dentro da porta digitando; além disso, muitas pessoas provavelmente contribuiriam para as conversões com mais eficiência, especialmente considerando a diferença entre a estética entre os comentários em bloco e em todas as linhas.

Meu maior caso de uso para essa implementação seria para pacotes de terceiros que não têm suporte a typescript, e eu precisaria ignorar alguns de seus usos.

@L-Hknu Obrigado por esclarecer. As pessoas o usam como ignoram com o ESLint de qualquer maneira.

A funcionalidade de ignorar não é desabilitada em contextos além de onde é necessária para a funcionalidade. Isso me diz que não há problema em usá-lo para ignorar o código.

Ainda não consigo raciocinar por que não deve haver nenhum bloco de ignorar, pois ele é usado da mesma maneira na maioria das vezes.

Eu abandonei a conversão para tipos para alguns códigos-fonte abertos, porque o progresso da conversão teria sido muito mais confortável com as ignorações de bloco. Eu não preciso disso, mas acho que muitas pessoas vão colocar um pé dentro da porta digitando; além disso, muitas pessoas provavelmente contribuiriam para as conversões com mais eficiência, especialmente considerando a diferença entre a estética entre os comentários em bloco e em todas as linhas.

Parece que está feito
#40267