necesito esto jajaja

El caso de uso actual para esta función es una prueba unitaria que trata con espacios en blanco. Tenemos la regla "sin espacios en blanco al final" activada en nuestra base de código por una buena razón, pero no poder dominarla a nivel de bloque significa que no podemos probar fácilmente los espacios en blanco al final y los retornos de carro usando una cadena de plantilla ES6 .

uno de mis casos de uso para usar paquetes personalizados _ a.k.a partial import _ en 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

Me gustaría ignorar los errores de un archivo completo. Heredé un código ES6 JS que me gustaría transpilar a ES5 pero tengo que usar Babel en este momento. Sería bueno simplemente cambiar el nombre del archivo a .ts y transpilar con TS.

@ptallett puede simplemente compilar archivos .js usando allowJs e incluirlo en la compilación. De manera predeterminada, no generamos errores en los archivos .js a menos que el archivo tenga un comentario // @ts-check en la parte superior o que active checkJs .

Todavía me encantaría esta funcionalidad, estoy sentado en un archivo de prueba, tiene la extensión .ts, por lo que puedo importar y ver fácilmente qué parámetros van a dónde, y compilarlo en un directorio junto a los archivos src es brillante para mi caso de uso .

La mayoría de mis líneas ahora están en rojo, ya que trato deliberadamente de excluir algunos parámetros, o de dar un tipo diferente a la función, del que toma originalmente, y espero que se produzca un error, ya que también lo verifico en tiempo de ejecución.

Sería maravilloso no tener un montón de líneas rojas por todas partes. :)

¿Hay alguna actualización al respecto, o alguien ha encontrado alguna buena manera de hacerlo?

Usar lodash y especialmente lodash/fp con TypeScript es muy doloroso, e incluso con las últimas versiones de lodash y @types/lodash puede terminar con mensajes de error muy crípticos.

Si podemos tener un @ts-ignore-block que ignore los errores del siguiente bloque, sería genial para casos de uso como este en los que _sabes lo que estás haciendo_ :-)

Estoy trabajando con código heredado con numerosas variables de alcance global, y escribir @ts-ignore en cada línea se vuelve tedioso, ¿alguna actualización sobre esto?

También buscando una actualización sobre esta solicitud. ¡Gracias!

Esto también sería muy importante para lo que estoy haciendo (es decir, la verificación de tipos de funciones de representación de plantillas Vue generadas, lo que requeriría deshabilitar inspecciones específicas para un bloque de código).
Junto con este problema, #19139 sería muy importante, porque especialmente cuando se aplica a grandes partes del código, solo querrá deshabilitar inspecciones específicas.

con la supresión del archivo de agujeros, esto podría agregarse a los editores como el código vs para guardar en la configuración del espacio de trabajo o similar.

También necesito esto. Estoy generando automáticamente un archivo ts completo con tipos para mi esquema GraphQL usando graphql-code-generator y hay una importación extraña que activa noUnusedLocals.

/* tslint: deshabilitar */

código

/* tslint:habilitar */

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

Se puede combinar con: 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 esto no es tslint.

A veces, mientras muevo cosas y refactorizo, quiero ignorar temporalmente todo el archivo (es decir, no compilarlo), sin jugar con las opciones de la CLI.

El más rápido/más fácil es una bandera en la parte superior del archivo:

// @ts-ignore-file

@lonix1 Su caso de uso está cubierto por:

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

No tienes que usar la parte // @ts-ignore-end . Muchas herramientas de pelusa funcionan de esa manera.

@mgol No quiero descarrilar este hilo... pero probé tu sugerencia, ¡gracias! - y no funcionó para mí. Junté las líneas en la parte superior del archivo y también probé una en la parte superior y la otra en la parte inferior.
¿Alguien más puede hacer que funcione?

@lonix1 Quise decir que la propuesta de @Blanen también funcionaría para usted, no necesitamos TypeScript para implementar // @ts-ignore-start + // @ts-ignore-end y // @ts-ignore-file , implementando // @ts-ignore-start + // @ts-ignore-end sería suficiente. Esto no está implementado, es por eso que este tema sigue abierto.

@DanielRosenwasser esto solo funcionaría cuando los archivos ts se almacenan en otra carpeta durante la compilación. cuando el proyecto está configurado para colocar archivos js junto a los archivos ts, no lo hará. ¿También se 'compilarán' los archivos js, por ejemplo, se transformarán a es5? Al transportar código heredado, esto sería realmente útil.

Necesita esta función.

Caso de uso:

TypeORM espera que creemos clases de entidad de base de datos que tengan columnas que pueden o no ser anulables. Muchas columnas (por lo tanto) no aceptan valores NULL... y por lo tanto deben tratarse, excepto en la definición de la clase, como si las propiedades fueran incondicionalmente de ciertos tipos definidos. Sin embargo, Typescript requiere que definamos cada columna como fuertemente tipada. Por lo tanto, terminamos con muchas 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 columna es obligatoria y (por lo tanto) segura de contener un valor, pero debido a la forma en que funciona TypeORM, cada propiedad debe definirse de tal manera que carezca de un inicializador. Sería extremadamente conveniente poder suprimir este problema específico/derivado de ORM en particular, para una clase completa (por lo tanto/o archivo).

@haggholm ¿ algún motivo para preferir ts-ignore a public metadata!: IEncryptedJSONContainer ?

@RyanCavanaugh ¡Ignorancia! Me había perdido esa característica en la documentación. Lo siento; por favor, no hagas caso.

me gustaría hacer

// @ts-ignorar-inicio
--strick cheques nulos, para un archivo en particular

Así es como se ve la prueba unitaria de campos y métodos privados con texto mecanografiado. Tengo 6 líneas dedicadas a ignorar el código. Horrible. Hace que mis ojos sangren. Cualquier solución alternativa para ignorar bloques sería muy apreciada.

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();
    }
});

Bueno, estaba a punto de agregar un nuevo problema, pero supongo que este problema lo cubre.

¡ @ts-ignore maneja las importaciones de varias líneas y de una sola línea de manera diferente!

Todavía hay muchos módulos npm que no tienen tipos o están escritos sin NoImplicitAny,
que dan como resultado un error "implícito", luego se importan:

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

Entonces puedo usar @ ts-ignore:

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

Pero cuando trabajo con importación automática y formateadores como Prettier, sucede lo siguiente:
(Formateado por Prettier)

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

Puedo arreglarlo con:

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

o

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

Pero luego comienza a verse así en las importaciones de una sola línea:

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

Así que tengo que escribirlo así porque la importación automática y el formato cambiarán entre la importación de una sola línea y la de varias líneas dependiendo de cuántos elementos se importen del módulo.
Realmente anula el propósito de la importación automática si tengo que cambiar el código de importación manualmente.

Sería bueno no tener que escribir ts-ignore-start y ts-ignore-end en cada importación,
Entonces: //@ts-ignore para la importación (no solo la siguiente línea) es, en mi opinión, algo que ts-ignore debería manejar. (O algún otro ignorado como: @ts-ignore-block / @ts-ignore-import )

necesito suprimir ciertos errores en todo el archivo:

// @ts-ignore-all TS1206

/*
... rest of the file
*/

De acuerdo con las personas anteriores que sugirieron // @ts-ignore-start y // @ts-ignore-end comentarios para manejar los casos de uso mencionados en este hilo.

Esto es bueno, porque se ve muy similar a la directiva // @ts-ignore actual, y le permite ignorar todos los errores en un archivo con solo la directiva // @ts-ignore-start en la parte superior.

Hay casos de uso positivos para varias de las sugerencias anteriores. Propongo:

@ts-ignore como comportamiento actual
@ts-ignore TSxxx [TSxxx ...] suprimir errores específicos
@ts-ignore-start bloque de inicio para ignorar
@ts-ignore-start TSxxx [TSxxx ...] suprimir error(es) específico(s) para el bloque
@ts-ignore-end bloque final
@ts-ignore-all suprimir errores para el resto del archivo
@ts-ignore-all TSxxx [TSxxx ...] suprimir errores específicos para el resto del archivo

Los "errores específicos" podrían incluir grupos con nombre similares a los de tsconfig o grupos definidos por el usuario de errores TSxxx.

No estoy seguro del valor de ignorar bloques que anidan módulos importados; mi preferencia haría explícitos los bloques ts-ignore dentro de los archivos de módulos importados. Pero al importar librerías de terceros, puede haber razones para esto, así que estoy indeciso aquí.

se busca el archivo .tsignore

como .npmignore y .gitignore

Debería haber un bloque de ignorar. Me quedé atascado con el marco del titiritero. En titiritero tiene el método "evaluar" que le permite ejecutar un bloque de script arbitrario en una página. Este bloque de script arbitrario podría contener una referencia a las funciones que están disponibles en la página; en otras palabras, la referencia a la función estaría disponible en tiempo de ejecución.

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

Esto será extremadamente útil cuando trabaje con fragmentos de código heredado, lo que hará que sea menos doloroso para la gente cambiar a TypeScript.

Sobre

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

Hice esta sugerencia antes y quiero cambiar la sintaxis.
O hazlo de principio a fin o de principio a fin
start y end (como verbos) no son antónimos y esto me molestaría para siempre si se mecanografiara.

eso esta bien conmigo

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

Funcionalidad muy necesaria.

¿Por qué esto todavía no es posible? :-(

Necesito bloquear ignorar también

+1

+1

¿Algún avance en esto?

🙏🏻

¿Y si lo hacemos igual que hacemos normalmente con eslint?

/* @ts-disable */

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

/* @ts-enable */

Como se mencionó anteriormente: tan pronto como esté generando código TS (por ejemplo, con swagger) donde, por ejemplo, pueden ocurrir vars no utilizados, necesita esta función.

+1

Sin //@ts-ignore-file es imposible migrar a TS

Entonces, Sin que nadie se dé cuenta , no es cierto.

@RyanCavanaugh La comunidad claramente necesita esto, ¿hay alguna razón por la que esto no se haya abordado? ¡Gracias!

Estoy luchando con esto en este momento, ya que ni siquiera puedo jugar con una solución que funcione para ver si es factible sin que Typescript llore y bloquee mi renderizado.

Actualmente necesitamos esta función.

Estamos importando una biblioteca pública que tiene tipos de nodo para algunas funciones que no nos interesan. Por lo tanto, sería bueno usar // @ts-ignore para una sola importación, en lugar de usar skipLibCheck para ignorar todas las librerías.

Inicialmente me gustó la idea de // @ts-ignore-file, pero // @ts-ignore probablemente funcionaría mejor en aras de la consistencia.

Entonces... Abrí #33383 con soporte para //@ts-nocheck en archivos mecanografiados. Ahora, siendo nosotros el equipo compilador de _TypeScript_, realmente no lo entendemos nosotros mismos (no solucionamos problemas probables, ¿¡qué!?!?) - incluso //@ts-ignore en mecanografiado solo se convirtió en una cosa porque nuestro brazo estaba torcido un poco, así que... dudamos... en agregar más mecanismos de supresión. Entonces, si realmente sienten que se requiere un mecanismo de supresión tan amplio, sería bueno que pudieran ir allí y 👍

@weswigham , si bien esta probablemente no sea la característica más importante. Podría ser útil durante el desarrollo. Al igual que comentar temporalmente algunas líneas de código, podría ser útil al desarrollar y tratar de aislar un problema en otro lugar. Sin embargo, me gustaría recibir una advertencia para que esta práctica no encuentre la manera de causar errores de tiempo de ejecución. Tal vez incluso habilite esta función solo para desarrollo, pero para generar un error en la compilación.

Dado que este problema todavía está etiquetado como "Esperando más comentarios", aquí hay más:

Al crear rápidamente prototipos de nuevas direcciones arquitectónicas, me gustaría hacerlo guiado por TypeScript, para asegurarme de que la nueva arquitectura funcionará. Sin embargo, quiero ignorar temporalmente los errores de tipo en los archivos de prueba de unidad , solo temporalmente, mientras experimento.

Agregar algún tipo de comentario @ts-ignore- en la parte superior de cada archivo sería bastante fácil.

Secundo la necesidad de @ kumar303 : en las pruebas unitarias, es beneficioso desactivar algunas comprobaciones para ese bloque/archivo dado, ya que serán las afirmaciones las que cubrirán esos casos.

@weswigham Podrías ponerlo detrás de una bandera del compilador.

Podrías ponerlo detrás de una bandera del compilador.

No es necesario, está en la versión 3.7 beta.

re: https://github.com/microsoft/TypeScript/pull/33383 : @weswigham eso es genial, ¡gracias! Un caso de uso poderoso aquí es ignorar temporalmente la verificación de tipos en un archivo, por lo que también sugiero enviar una regla de pelusa que falla cuando uno se olvida de eliminar @ts-nocheck

Tengo un problema en gatsby, donde una consulta de graphQL estática funciona en archivos .jsx , pero no en archivos .tsx . Creo que esta propuesta podría ser una solución alternativa más aceptable. (problema aquí https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5)

¡Oye!
¿Se ha implementado la solución propuesta?

// @ts-ignorar-inicio
// @ts-ignorar-fin

Creo que sería muy beneficioso. No me importaría trabajar en ello.

Agregamos soporte para //@ts-nocheck para suprimir todos los errores en un archivo completo en 3.7. Creo que la supresión a nivel de línea y de archivo puede abarcar _la mayoría_ de las necesidades sin mucho alboroto. Si tiene un bloque lo suficientemente grande dentro de un archivo marcado que debe desmarcarse, tal vez simplemente deshabilite la verificación de todo el archivo o, si eso es desagradable, extraiga el fragmento no verificado a su propio archivo y deshabilite la verificación de ese archivo o, en su defecto, suprimir cada línea con un problema real? Se supone que un ts-ignore ignora un solo problema, mientras que un ts-nocheck debe ignorar un solo archivo: una supresión basada en rango en realidad no se asigna a una unidad específica de ninguna manera, por lo que parece de alguna manera peor (ya que no se puede asignar a un solo problema o causa raíz que está suprimiendo). Al menos sin supresiones específicas de código de error, no me siento particularmente cómodo con las supresiones basadas en rango.

Yo, al menos, preferiría una sola supresión ( //@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 ) en la parte superior del archivo o supresiones individuales ( //@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 ) en cada cosa mala individual (tm). No puedo, por mi vida, presentar un ejemplo convincente y basado en principios en el que se deba permitir que se desmarquen _rangos_ específicos de código (a diferencia de los archivos, que tenían un razonamiento claro respaldado por una estrategia de migración), que no sea "escribir múltiples las supresiones me hacen sangrar los ojos", por lo que tengo _cero_ simpatía ya que, fundamentalmente, creemos que no debería usar supresiones en TypeScript en absoluto. Si se trata de un problema de tipo, puede eliminarlo (es por eso que existen any , conversión y declaraciones de módulos abreviados). Si se trata de un problema de sintaxis, todo es horrible y de todos modos estaremos rotos, por lo que las supresiones no harán nada (las supresiones no afectan los errores de análisis).

Gracias por //@ts-nocheck , pero esto no resuelve el problema de deshabilitar la verificación del bloque de código:

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

// @ts-nocheck

Tengo un caso de uso interesante.

Construimos o poseemos ORM en Typescript que usa bellota para compilar declaraciones en nuestro DDL.

Para hacer una consulta where tenemos que pasarle variables de alcance:

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

Esto no funciona simplemente porque: Property 'id' does not exist on type 'xxx'

Si lo envuelvo en @ts-ignore-start funcionará bien así:

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

Pero cuando llega el formato y comienza a agregar saltos de línea:

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

ya no funciona

Esto no funciona simplemente porque:

Ese es exactamente el tipo de error de nivel de tipo para el que debe tener un as any emitido (o, en jsdoc, /** <strong i="8">@type</strong> {any} */(expr) ) en el(los) acceso(s), si realmente desea suprimirlo.

//@ts-nocheck no funciona para mi proyecto ts angular pero //@ts-ignore sí. Este problema para Microsoft comenzó en 2017. ¡2017! Guau...

3 años ya y sin solución. No sorprende que los desarrolladores de JavaScript no quieran dar el salto a mecanografiado

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

Se puede combinar con: #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 esto no es tslint.

¿Algún plan para implementar esto?

// @ts-nocheck
es la única opción actualmente :(

Otro caso de uso para agregar para su consideración aquí...

Soy un código que genera un montón de código TypeScript a partir de un lenguaje de marcado interno que permite un flujo de control básico y condicionales. Si bien controlo el comportamiento de generación de código, no controlo las entradas que se pasan al generador de código (eso depende de los usuarios finales)

Como resultado, el código generado puede tener fácilmente un código inalcanzable, o en un caso TS2367, ya que puede haber un código anidado que prueba un valor contra una constante de enumeración, luego dentro de ese bloque contiene otra verificación de esa variable contra otra constante de enumeración. Por ejemplo:

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

Con código escrito a mano, este patrón es fácil de arreglar y evitar. Sin embargo, con la generación de código, depende de mis usuarios (desarrolladores, ¡usted conoce el tipo!) No proporcionar entradas que prueben innecesariamente valores imposibles.

No deseo deshabilitar la verificación de tipos por completo, pero no tengo otro mecanismo para consumir el código generado por este error. Idealmente, suprimiría este error para todos los archivos generados por código, pero mantendría todas las demás comprobaciones de tipo.

Tal como están las cosas, no tengo otra solución que desactivar la verificación de todos los tipos. En ese momento, no obtengo mucho valor de TypeScript frente a JavaScript simple

¿En serio? ¿Esto sigue siendo un problema abierto y no está implementado en TS4? 🤦🏽

@ivnnv Puede usar // @ts-expect-error en TS 3.9, vea aquí

@ndraiman @ts-expect-error funciona para líneas individuales pero no para bloques , por lo que todavía es necesario colocar muchos de ellos si se quiere "ignorar un bloque"

Aquí hay algunos comentarios más para usted:

Que más necesitas? ¿Qué tiene que hacer la comunidad para obtener esta funcionalidad?

El mejor caso de uso para esto es la alternativa a escribir any en cada uno de los tipos que se están haciendo. Es posible que no tenga simpatía por la estética (que sin duda tiene un impacto en el estado de ánimo y la productividad), pero tener una alternativa que coincida con las expectativas comunes no debería ser difícil de aceptar.

Las personas tienen diferentes puntos de vista sobre lo que es aceptable y lo que no lo es.

Para algunas personas, consume demasiado tiempo y limita el estado de flujo en el que pueden estar las personas mientras hacen cosas mundanas como portar código.
Me resulta molesto y extraño que no pueda tener un bloque de código ignorado, sino que tengo que ensuciarlo con moldes any , lo que a menudo tiene un efecto perjudicial en la legibilidad (hasta que los tipos adecuados están ahí). Tener que escribir continuamente un nuevo comentario o permitirse una distracción, solo porque alguien no ve el beneficio de ignorar bloques de código, no está bien desde mi perspectiva.

EJEMPLO:

Uno es portar un proyecto de JS a TS, mientras que el otro proyecto está siendo desarrollado por un tercero.

La sintaxis y las reglas seguidas en el proyecto portado pueden ser antiguas, por ejemplo, es2015, u obsoletas a favor de una sintaxis más clara y menos código, etc.

Al migrar este proyecto, parte del código puede ser extremadamente fácil de migrar a TypeScript. Aun así, uno inevitablemente se topa, por ejemplo, con booleanos y funciones a medio pensar con un comportamiento arbitrario que necesita más contexto o tiene que pensarse durante algún tiempo para crear sus tipos.

Sería increíble dejar de verificar una función o un bloque de código en un archivo mientras lo arregla. Ignorar un bloque de código permitiría moverse rápidamente en las áreas que conocen y con las que se sienten cómodos y guardar ciertas partes para más adelante.

Mi flujo de trabajo cuando tengo que portar JavaScript a TypeScript (y el código es, bueno, mediocre):

1. Copie el código del archivo .js al archivo .ts.
2. Vea si TS puede inferir algún tipo por uso
3. Comprender manualmente los tipos de uso
4. Darme cuenta de que los errores son la ruina de mi existencia
5. Intente comentar los errores, mejorando así el número de líneas en el archivo a veces x3 ESLlint + TS (¿más es mejor?)
6. Elimine y agregue // @ts-check en la parte superior mientras edita cuidadosamente el resto de los archivos y agrega más tipos.

Si pudiéramos ignorar los bloques:

1. Copie el código de .js a .ts
2. Vea si TS puede inferir algún tipo por uso
3. Comprender manualmente los tipos de uso
4. // @ts-ignore-enable ... // @ts-ignore-disable funciones individuales y bloques de código problemáticos
5. Descomente los bloques a medida que llego a ellos y agrego tipos

Decide por ti mismo lo que te parezca más razonable. Es lo mismo cuando se transfiere JS a un proyecto con muchas más reglas de ESLint, y tiene que refactorizar la mayoría de las cosas.

Ojalá pudiéramos hacer lo que es posible en ESLint y usar /* eslint:disable */ ... /* eslint:enable */ en TypeScript.

PD: Al revisar este comentario, me acabo de dar cuenta de que pasé más de 20 minutos tratando de obtener una experiencia que yo (y muchos otros) hemos estado buscando desde 2017, solo para comentar sobre un tema abierto que pronto tendrá 3 años.

@weswigham @RyanCavanaugh

Recordatorio :+1:

Dará primogénito a cambio de esto

@agusterodin Tu sacrificio llama la atencion de los males.....

Muy bien, de hecho, no pasa nada, excepto que solo doy un PR simple :)

Sin embargo, personalmente, estoy totalmente de acuerdo con la opinión del equipo de TS: esta función es mala, siempre debe tratar de evitar usar @ts-ignore , no usar @ts-ignore-enable (o @ts-ignore-start , lo que).
Pero a veces, ya sabes, el proverbio dice drinking posion to satisfie thirst , sé que es una mala elección, pero es solo una necesidad.

editar: agregar explicación y ejemplos.
Este PR agrega dos directivas ts-ignore-enable y ts-ignore-disable .

1. si solo usa ts-ignore-enable, el resto se ignora.

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

1. podría agregar las mismas directivas muchas veces, pero solo funcionan una 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 podría usarse solo, no pasaría nada.

2. @ts-expect-error no funcionaría en la región 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. sin etiqueta de región, son solo comentarios.

// @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.

En un mundo perfecto, no necesitaríamos ignorar la seguridad tipográfica, ¿verdad? :sudor_sonrisa:
Lo necesito cuando copio un trabajo fantástico, por ejemplo, ejemplos y arrancadores, incluso la respuesta SO ocasional que no está escrita o escrita como me gustaría. Principalmente para tenerlo en mi código de tipo seguro que sigue mi configuración. Solo uso configuraciones muy estrictas y, a menudo, tengo que volver a escribir una función o alguna lógica debido a eso. No es porque quiera seguir ignorando ese bloque de código, eso no tendría sentido.

Ignorar un bloque de código es una conveniencia, que para mí parece perfectamente razonable dado el hecho de que todavía puedo @ts-ignore cada línea en un bloque.

Entiendo las posibles implicaciones que esto podría tener para las personas que buscan I'll just ignore this because it's easier . Tal como lo veo, cualquiera que pueda usar el alcance de bloqueo ignora drink poison to satisfy their thirst ya está bebiendo gotas de veneno con @ts-ignore .

Ahora que puede hacer @ts-nocheck en archivos .ts , sugiero permitir @ts-check en archivos .ts también para que podamos activar/desactivar el 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

Esto no requiere definir qué es un "bloque de código". Puede iniciar y detener la verificación de tipos desde - a cualquier línea.

ACTUALIZAR Me equivoqué, consulte https://github.com/microsoft/TypeScript/pull/40267#issuecomment -713840095 para la corrección.

Al intentar migrar una aplicación usando styled-components a TypeScript, me encontré con un problema en el que @ts-ignore no se puede usar sobre las cadenas de plantilla (por algún motivo). Podría haberse resuelto con un bloque de ignorar.

Ejemplo del error de TS que estaba tratando de ignorar:

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

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

Como nota adicional: no puedo lanzar ninguno en mi proyecto TS, no permito ningún tipo. ¿Cuál es la recomendación entonces?

@weswigham ¿Cuáles son sus pensamientos sobre el estado de flujo y la productividad en el contexto de la estética? Parece que no sientes simpatía por los ojos sangrantes; pero, ¿tiene alguna noción sobre productividad, portabilidad de código y los procesos que describí? ¿ Todavía no ve ningún beneficio _en absoluto_, después de considerar mi comentario, y en el contexto de ser más productivo? También describí algunas situaciones reales en las que uno necesitaría ignorar el alcance del bloque. Además, ¿cómo no se compara esta funcionalidad con ESLint y la funcionalidad que esperamos allí?

Está científicamente probado que menos interrupciones aumentan la productividad y mejoran la eficiencia; ignorar el alcance del bloque permitiría menos interrupciones al portar el código. ¿El equipo de TS no se da cuenta de que "fundamentalmente, creemos que no debería usar supresiones en TypeScript en absoluto". es una opinión basada en vivir y respirar TypeScript, y que en el mundo real, las personas necesitan portar código mal escrito a otras bases de código, con más seguridad de tipo y otras reglas de linting; en esas situaciones, no tiene sentido que pueda ignorar un archivo o una línea, pero no el bloque de código que acaba de importar.

Para mí, parece que vas por la utopía mientras ignoras la realidad. @sandersn No abordó ninguno de mis puntos y mantuvo la respuesta anterior sobre las discusiones más nuevas en el caso. También afirma que, a menos que el equipo decida lo contrario, no debe implementarse, en cuyo caso: ¿cerrar el problema?

El equipo necesita tomar una decisión o implementar una característica claramente deseada.

Mantener el tema en el limbo no tiene ningún sentido.

Lamento que no podamos darle la finalidad que necesita, pero la realidad es que "tal vez más tarde" es una respuesta con la que tendrá que aprender a vivir. Cualquier característica dada no puede ser apresurada en el producto mañana, y para las características que caen dentro de nuestros parámetros de diseño, hay miles de sugerencias actualmente abiertas que compiten por nuestra capacidad para agregarlas al producto de una manera que sea ergonómica, útil, estable y con visión de futuro.

Priorizamos las cosas en función de los comentarios actuales, el estado de las soluciones y soluciones actuales, la preponderancia de esos escenarios, las herramientas y otros cien factores. Las cosas que no son de alta prioridad en este momento pueden volverse de alta prioridad más adelante. Esa es la naturaleza de "tal vez más tarde" y creo que es una representación precisa de dónde se encuentra esta sugerencia. La decisión aquí, por ahora, es continuar monitoreando los comentarios y comprender con qué se está encontrando la gente que podría necesitar que esta función sea de mayor prioridad que cualquier otra función que podamos agregar a continuación, de las cuales hay cientos compitiendo por atención.

El tono aquí tiende honestamente a ser hostil y hablando personalmente, ser empujado hacia un ultimátum no conduce a una conversación constructiva que nos ayude a comprender dónde está agregando valor que supera su complejidad en relación con las alternativas.

Lamento haber puesto un ultimátum. Me molestó bastante ver actividad hacia el PR, pero ninguna sobre el tema. Estoy de acuerdo en que mi comentario anterior no contribuye de ninguna manera constructiva.

Puedo aceptar que este problema podría necesitar esperar. Proporcioné algunos comentarios y pregunté qué otros comentarios son necesarios para acercarme a la resolución, pero no obtuve respuesta. Parece, por molesto que sea, que mi comentario bastante poco constructivo era lo que necesitaba hacer para obtener _alguna_ respuesta del equipo.

Todavía parece que no se ha hecho ninguna progresión real hacia un problema con más de 700 reacciones positivas, que tiene varios años. No creo que deba ir más rápido, pero parece que el equipo no está interesado en explorar esta función ya que los miembros tienen opiniones personales en contra. Entiendo completamente todas estas cosas. Sin embargo, eso no es lo que estoy hablando aquí. Quiero entablar una conversación, pero me ignoran.

Me gustaría saber que mis comentarios son considerados y, dada la naturaleza de los mismos, respondidos. No es una gran interrupción en el conjunto de funciones, como lo demuestran las relaciones públicas activas que se prepararon en poco tiempo. Todo está listo para funcionar, la gente sigue reaccionando positivamente para resolver este problema con una función de ignorar bloqueo, y intervine para preguntar qué tiene que hacer la comunidad para obtener esta función. Estoy totalmente en desacuerdo con varios de los puntos que se hicieron por parte del equipo y he argumentado en contra, se hizo un PR y se hizo un comentario que decía que "a menos que cambiemos de opinión" , nada cambiará.

Ahí es donde mi frustración sale a la superficie. Desea descartar una función lista porque no se han realizado cambios hacia una decisión de un miembro del equipo, ignorando por completo mis propios comentarios y los de otras personas.

Parece que a menos que alguien del equipo decida lo contrario _por su propia voluntad_, no veremos ningún cambio en este tema. Eso no requiere más comentarios de la comunidad, ¿verdad? Por eso hice mal el ultimátum.

Presenté varios argumentos en contra de los puntos de @weswigham , proporcioné algunos ejemplos y, sinceramente, todavía estoy esperando algún tipo de respuesta. Lo único que parecía ayudar era estar visiblemente molesto y poco constructivo.

¿Cómo nos movemos de aquí? ¿Qué comentarios le gustaría al equipo? Parece un problema personal oculto detrás de "Priorizamos las cosas en función de los comentarios actuales, el estado de las soluciones y soluciones actuales, la preponderancia de esos escenarios, las herramientas y otros cien factores". ya que varias personas han intentado dar su opinión sin recibir ninguna respuesta del equipo.

Me gustaría reiterar que entiendo que esto podría no ser una alta prioridad si quitamos las opiniones de las personas sobre el tema. Al mismo tiempo, la función está lista para implementarse y se han presentado argumentos. Lo que se necesita ahora es que el equipo tome una decisión/respuesta (no necesariamente implemente nada) y la haga pública. Si eso no es lo que se requiere, entonces dígame qué es, o cómo ayudaría a aumentar la prioridad en _cualquier_ función o problema para TypeScript, pero especialmente este.

Otro caso de uso para multilínea ( @ts-ignore-start+@ts-ignore-end ) o en línea (como /* @ts-ignore */ ) @ts-ignore .
Ambiente:

• "noUnusedParameters": true
• Regla ESLint require-jsdoc habilitada.
• Código similar al siguiente (ejemplo 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 la situación descrita, TypeScript emite la siguiente advertencia: 'settings' is declared but its value is never read.(6133) .
Es posible suprimir la advertencia agregando @ts-ignore después del final del comentario de la documentación:

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

Pero después de eso, ESLint se quejará de Missing JSDoc comment .
Entonces la solución es:

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

Lo cual es incómodo y feo.

@RyanCavanaugh @weswigham @sandersn

Un recordatorio mensual de que esto es algo que la comunidad quiere discutir más a fondo con el equipo de TypeScript. Hay mucho apoyo y lo que falta actualmente es una respuesta del equipo. Entiendo que hay mucha preponderancia, y progresar en TypeScript no es tarea fácil. Las cosas toman tiempo. Dado que no hay respuesta sobre cómo podemos promover esta sugerencia y tomar medidas más directas, haré un recordatorio como este regularmente. No me rendiré hasta que se haya tomado una decisión, y comentar parece afectar (sobre todo cuando se es un !@#).

Después de que pasaron estos años, aunque originalmente me asustó que esta funcionalidad no estuviera allí, personalmente lo reconsideré un poco... Cuando hay una gran cantidad de @ts-ignore , es posible que ya sepas que hay algo mal. con su código y dedique algo de tiempo a mejorar sus tipos. Todos somos bastante perezosos a veces y queremos velocidad en general, pero actualmente suele ser más fácil averiguar algunos tipos adecuados en lugar de copiar y pegar varios @ts-ignore en grandes grupos de código. Si se rompe este equilibrio de INconveniencia, muchos de nosotros abusaremos convenientemente de @ts-ignore-enable, lo que podría disminuir la calidad general de todos los pequeños proyectos de código abierto aquí y allá.

Por cierto, aunque vemos que hay muchas 👍 reacciones sobre este tema, podría ser parcial, porque muchas más personas podrían sentirse completamente bien sin esta función mientras están en silencio, porque no están aquí.

@JerryGreen Haciendo referencia a mis comentarios anteriores, he dicho exactamente lo mismo. Con la adición de que la gente ya está haciendo esto con la función de ignorar. No hay razón para implementar un poco de veneno mientras se afirma que no debería haber _ninguno_ .

Quite la funcionalidad @ts-ignore o hágala completa. Hay muchos argumentos para hacer esto, y las personas que escriben código incorrecto continuarán usando @ts-ignore que es tan malo como una función de ignorar bloque, son exactamente lo mismo, excepto que ignorar bloque es menos disruptivo visualmente.

La comunidad aún necesita una respuesta del equipo de TypeScript.

@JerryGreen Haciendo referencia a mis comentarios anteriores, he dicho exactamente lo mismo. Con la adición de que la gente ya está haciendo esto con la función de ignorar. No hay razón para implementar un poco de veneno mientras se afirma que no debería haber _ninguno_ .

Quite la funcionalidad @ts-ignore o hágala completa. Hay muchos argumentos para hacer esto, y las personas que escriben código incorrecto continuarán usando @ts-ignore que es tan malo como una función de ignorar bloque, son exactamente lo mismo, excepto que ignorar bloque es menos disruptivo visualmente.

La comunidad aún necesita una respuesta del equipo de TypeScript.

Algunos escenarios especiales aún necesitan usar @ TS ignore. Por ejemplo, la importación de CDN no depende de node_ The. El archivo TS no existe en el escenario de módulos

@ L-Hknu Gracias por aclarar. La gente lo usa como usa ignora con ESLint de todos modos.

La funcionalidad de ignorar no está deshabilitada en contextos que no sean los necesarios para la funcionalidad. Eso me dice que está bien usarlo para ignorar el código.

Todavía no puedo razonar por qué no debería ignorarse un bloque, ya que se usa de la misma manera la mayor parte del tiempo.

He abandonado la conversión a tipos para algunos códigos fuente abiertos, porque el progreso de la conversión habría sido mucho más cómodo con los bloques ignorados. No lo necesito, pero creo que mucha gente metería un pie dentro de la puerta; además, es muy probable que muchas personas contribuyan a las conversiones de manera más eficiente, especialmente dado lo diferente que es la estética entre los comentarios de bloque y de cada línea.

Mi caso de uso más importante para esta implementación sería para paquetes de terceros que no tienen soporte para escritura mecanografiada, y necesitaría ignorar algunos de sus usos.

@ L-Hknu Gracias por aclarar. La gente lo usa como usa ignora con ESLint de todos modos.

La funcionalidad de ignorar no está deshabilitada en contextos que no sean los necesarios para la funcionalidad. Eso me dice que está bien usarlo para ignorar el código.

Todavía no puedo razonar por qué no debería ignorarse un bloque, ya que se usa de la misma manera la mayor parte del tiempo.

He abandonado la conversión a tipos para algunos códigos fuente abiertos, porque el progreso de la conversión habría sido mucho más cómodo con los bloques ignorados. No lo necesito, pero creo que mucha gente metería un pie dentro de la puerta; además, es muy probable que muchas personas contribuyan a las conversiones de manera más eficiente, especialmente dado lo diferente que es la estética entre los comentarios de bloque y de cada línea.

parece que ya esta hecho
#40267