Acordado. Anhelo de algo como @SuppressWarnings Java, en particular para el caso que se describe aquí :

El seguimiento:

const typeMetadataKey = Symbol('type');

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

Produce el error: Unable to resolve signature of class decorator when called as an expression. .

Cuando se usa de la siguiente manera:

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

El decorador funciona como se esperaba y compilará, pero da el error anterior.

Si tiene pensamientos sobre cómo podría resolverse esto, feliz de indagar en él si alguien quisiera señalar la dirección correcta.

Solo échalo (el reparto no es un término oficial, sino el mismo concepto)

const foo: string = 7 as any;

¿Es eso lo que estás buscando?

Solo di un ejemplo, no es realmente un caso (lo sé todo sobre el casting), tengo otros casos como
super siendo llamado después de la primera línea del constructor y otros problemas ...

• hará que la transición a TS sea más fácil desde JS + en algún momento, cambie una biblioteca y obtenga toneladas de errores y solo quiera limpiar las cosas como lo conoce como desarrollador por la razón ...

Esta es una característica importante

Entonces, ¿algo como // tslint:disable ?
¿Posiblemente incluso permitiéndole activar / desactivar comprobaciones específicas que tsc realiza?
_eg: _ const FooBar: string = 'rozzzly'; // tslint:disable-line camelcase

que sería increíble...

No lo sé ... Creo que eso podría estar fuera del alcance de tsc . Para eso están los linters.

tiene que ser capaz de "callarlo" :)

Creo que hay motivos para suprimir errores / advertencias en funciones "experimentales", como decoradores, donde la API es un poco volátil y los errores pueden no siempre ser precisos. Obtiene una versión (muy específica) de esto simplemente usando el campo tsconfig "experimentalDecorators", pero solo suprime un tipo de advertencia.

Para jugar al abogado de mi propio diablo, esto podría alentar a los nuevos usuarios de TypeScript a suprimir las advertencias que no comprenden en lugar de aprender por qué ocurre la advertencia. Y con las funciones experimentales, todo el mundo es una especie de usuario nuevo: tener la capacidad de eliminar errores podría hacer que los usuarios se sientan satisfechos con los errores en las nuevas funciones, en lugar de problemas de apertura.

En última instancia, todavía quiero que mi salida de Syntastic esté limpia. Lo que significa suprimir el error. Por supuesto, eso sería _después_ de abrir el problema por un posible error e intentar obtener más información. ;)

El problema de "callarlo" es que no sabes lo que obtienes de "eso". también lo es let a:string = 1 a number o string ?, ¿y si hay otra declaración de a , se fusiona o no? ¿Qué pasa si alguien captura el tipo de esta variable, por ejemplo, return {a} ; , deberían ser asignables a { a : number } o { a: string } , o ambos?

una cosa fundamental, los errores son todos innobles. los errores no bloquean la generación de salidas, ni el herramental.

Existen diferentes mecanismos que le permiten suprimir la verificación de ciertas partes de su código, por ejemplo, any , aserciones de tipo (casts) y declaración ambiental.

así, por ejemplo, si tiene una biblioteca que tiene una definición "inválida", puede simplemente eliminarla y reemplazarla con declare module "blah" { export = any } . o declare var $: any y ya está listo.

Como suelo responder a estas solicitudes, creo que su problema no es eliminar el error. el problema real es que tiene un error que no le resulta útil. Suprimir que no resuelve el problema subyacente, solo lo cubre y tiene ramificaciones de un estado inconsistente sin advertencia. La solución correcta es saber cuál es el error que está obteniendo. que biblioteca es? y por qué el compilador le está dando un error inútil ...

Y para ello, necesitamos saber más sobre su caso de uso.

Hemos trabajado en TS 2.0 para resolver algunos de estos problemas subyacentes, por ejemplo;

• Admite declaraciones abreviadas de módulos ambientales y caracteres comodín en los nombres de los módulos, lo que permite una manera fácil de deshabilitar un módulo completo o incluso un conjunto de módulos, por ejemplo, declare module "@angular\*";
• La resolución del módulo cambia para permitirle anular desde dónde se carga una definición de módulo
• permitiendo definiciones duplicadas con el mismo tipo en archivos .d.ts
• nuevo --skipLibCheck para no escribir comprobar ningún archivo .d.ts
• soporte para --typeRoots para permitir anular desde dónde se cargan los archivos de declaración

solo use cualquiera, así es como "cállate", los méritos de hacerlo (o en realidad la falta de ellos) es una pregunta diferente

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

ok, pero de nuevo, el problema no está específicamente en la transmisión

<any> le ofrece un javascript vanila con 100% de libertad de todas las cosas molestas de TypeScript, entonces, ¿qué más necesita?

en mi caso llamo super no como primera línea de constructor y necesito silenciar el error

En lugar de intentar forzarlo a aceptar un antipatrón, ¿por qué no escribir, prueba algo como esto?

_ _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');
    }
}

Esto es lo que hace que el mecanografiado sea tan asombroso, _y también molesto_. Te obliga a escribir mejor código y te convierte en un mejor desarrollador. Convertir un proyecto no es

en mi caso llamo super no como primera línea de constructor y necesito silenciar el error

Y haz que tu código sea incompatible con ES6 ... Que es exactamente la razón por la que el propósito principal de TypeScript es quitar 👣: gun: de tus manos.

Si TypeScript no está interpretando algo bien, entonces debería arreglarse en lugar de "solucionarse". Ahora hay algunas cosas en las que TypeScript actúa más como un linter y todavía no existe un concepto de "error" frente a "advertencia". Puedo ver las advertencias suprimidas cuando llegan. Cosas como el código después de la devolución y los parámetros no utilizados deberían ser advertencias en mi opinión, porque son sintácticamente correctos (aunque estúpidos).

aquí hay otro caso en el que me encantaría tener esta función:

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

Ahora mismo hay un error de ts:

[ts] La clase 'Perro' implementa incorrectamente la interfaz 'Animal'
Falta la propiedad 'numberOfLegs' en el tipo 'Perro'

Como puede ver, el compilador está totalmente equivocado, pero no quiero (y no debería estar obligado a) copiar todas las propiedades de la interfaz solo por el bien del compilador.

@DethAriel Básicamente, lo que está pidiendo es una forma de expresar los efectos secundarios posteriores a la condición en el sistema de tipos. Eso es interesante, pero tengo la sensación de que conduciría a un código terriblemente complicado.

@aluanhaddad Sí, lo entiendo totalmente. Pero aún así, no veo una solución que no sea fea para eso, excepto copiar y pegar los miembros de la interfaz, lo cual no es ideal al menos. Es por eso que creo que tener la capacidad de cerrar la salida de error del compilador tiene sentido: todos somos personas inteligentes aquí, y el compilador debe confiar en nosotros cuando se lo digamos.

Solo usa una combinación de interfaz + clase

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 , eso funcionó de hecho

¿Qué pasa si el error no se puede <any> eliminar?

Estoy usando la sintaxis de enlace experimental como se describe aquí https://github.com/Microsoft/TypeScript/issues/3508 y, aparte de no usarla, no puedo hacer que el compilador ignore el error en cada línea antes de cada :: operador ( TS1128: Declaration or statement expected )

Estoy usando la sintaxis de enlace experimental

esto es realmente más que descartar una advertencia. El analizador no lo admite, por lo que el árbol resultante es completamente incorrecto, todas las características del compilador a partir de este momento no funcionarán, por lo que no hay inferencia de tipos, verificaciones de compatibilidad, formateo, finalización, nada. por lo que sería mejor ignorar todos los errores o simplemente trabajar en un archivo .js.

Actualmente estoy convirtiendo un gran proyecto JS en mecanografiado y después de hacer la conversión cuando ejecuto el comando gulp build veo alrededor de 2000 errores de TS durante la compilación y la mayoría de los errores están relacionados con la propiedad no definida en una clase o módulo no definido. Creo que debe haber alguna forma de suprimir este tipo de errores a medida que se generan los archivos JS de salida.

Este es exactamente mi caso también, convierto una aplicación creada con un diseño de módulos como propiedades anteriores a ES6, por lo que tengo un ENORME app.namespace1.namespace2.something.views.view -like global object.

Reescribo una parte de él y DEBO depender del objeto global app. * Y sus diferentes subelementos en mi código. Todo lo que obtengo es una gran cantidad de advertencias de "No se puede encontrar la 'aplicación' del espacio de nombres".

He refactorizado todas mis dependencias globales a un globalProxy.ts, por lo que este es el único lugar donde recibo las advertencias, pero sería INCREÍBLE agregar un // TS-NO-WARNINGS en la parte superior de este archivo para limpiar la consola de los mensajes obvios ...

Los errores de TS no bloquean la generación de código. Puede optar por ignorarlos, pero lo que le dicen es que el compilador no puede afirmar la exactitud de su código.

@ zeeshanjan82 ¿ --allowJs y migrar archivo por archivo? Con esa configuración, no obtendrá errores de tipo de fuentes de JavaScript. También puede utilizar una declaración de comodín ambiental para suprimir errores de resolución del módulo como
_globals.d.ts_

declare module '*';

Aquí hay otro caso de uso para la supresión de errores.

Los mantenedores de la biblioteca de momento olvidaron agregar isoWeek como una cadena válida al parámetro enum para los métodos startOf y endOf . Se corrigió en una versión posterior, pero al hacerlo, refactorizaron por completo la forma en que se manejan estas unidades, lo que causaría demasiados reprocesos por nuestra parte.

Así que arreglamos la versión del momento en su lugar, pero ahora esencialmente no podemos usar isoWeek debido a errores de lanzamiento de TS. Tan atrapado entre la espada y la pared en este momento.

podría simplemente agregar una copia local. di algo tan simple 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
        }
    }
}

ahora el compilador comparará su copia local de override/moment.d.ts lugar de la que viene con el paquete. obviamente, esto puede ser una copia local del archivo de declaración de momento o un pequeño conjunto de cosas que necesita.

Me falta el tiempo y el deseo de mantener mis propias definiciones de mecanografía para bibliotecas de terceros;)

Me falta el tiempo y el deseo de mantener mis propias definiciones de mecanografía para bibliotecas de terceros;)

Y eso está perfectamente bien. simplemente use declare module "moment"; que es el equivalente a declare var $: any para los módulos, y el compilador no volverá a molestarlo.

La sugerencia de @mhegazy es muy buena. Le llevará unos 20 segundos hacerlo. Por cierto, con respecto al momento, se olvidaron de un par de unidades que estaba usando y estuvieron muy abiertos a aceptar mi solicitud de extracción.

La desventaja de agregar declare module "moment"; es que ya no tendrá ningún intellisense IDE o verificación de tipo estático para ningún código relacionado con el momento. Y los any s que surgen tienden a desangrarse en el código circundante, cerrando muchas verificaciones estáticas allí también. Es un precio muy alto a pagar por suprimir los errores relacionados con un único valor de enumeración problemático.

@aluanhaddad había una solicitud de extracción abierta para solucionar el problema, pero se cerró a favor de otra, que introdujo cambios importantes (y aún no agregó soporte para isoWeek ), así que no estoy seguro de qué sucedió allí. .

El punto es que estos problemas seguramente surgirán con más frecuencia en el futuro con la adopción de Angular 2, etc., por lo que me imagino que sería útil una forma de eliminar errores particulares.

Tengo este problema con una biblioteca central de nodo (red, nodo 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; }'.'

Y también con la biblioteca ioredis:

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

Como señalaron @yortus y @adamreisnz , este es un problema común ya que los archivos de definición no siempre se actualizan correctamente. Además, si tiene que sacrificar los beneficios de TS usando declare module "x"; ¿por qué usaría TS en primer lugar?

También puede aumentar el módulo con los tipos que faltan para no perder la inteligencia.

Bueno, cuando escribo:

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

El compilador mecanografiado siempre informa un error Cannot find name 'Symbol' si target es es5 , aunque este código funciona bien tal como esperaba.

Así que estoy de acuerdo en que necesitamos urgentemente algunas directivas de control que funcionen en las líneas de comentarios.

declare var Symbol: any;

@ gdh1995 @mhegazy O simplemente use la solución real que es establecer la bandera lib en es2015 .

@mhegazy Gracias. Encuentro que esto funciona bien:

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

@DanielRosenwasser Aunque es2015 agrega estas útiles características, mi proyecto está limitado a ser compatible con es5 y luego Symbol debe evitarse en otros archivos.

Lo que no entiendo ahora es que el compilador de TypeScript me da errores incluso cuando escribí typeof Symbol === "function" . ¿Algún consejo?

Un caso que me encantaría tener es el de burlarse de las dependencias:

// 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 tiene el efecto deseado de hacer que la dependencia sea simulada dentro del componente probado, pero TypeScript arroja un obvio "No se puede asignar a 'Dependencia' porque no es una variable". error.

Estoy seguro de que la respuesta será que estoy ladrando al árbol equivocado y debería estar usando algo como inject-loader pero, según mi experiencia, esas soluciones A) son un dolor de cabeza para trabajar / no siempre trabajo y B) no son tan simples como los anteriores. Como mencionó OP, a veces el desarrollador sabe más. Sé que esta es una solución hacky pero funciona y me encantaría que TS se callara en este caso.

Este código tiene el efecto deseado de hacer que la dependencia sea simulada dentro del componente probado, pero TypeScript arroja un obvio "No se puede asignar a 'Dependencia' porque no es una variable". error.

este es un error en ES6. por lo que en algún momento en el futuro, cuando los motores admitan módulos ES6 de forma nativa, será necesario reescribir sus pruebas.

Alternativamente, puede hacer que su ComponentToTest acepte un argumento para Dependency , y sus pruebas pueden pasar eso, o tener un gancho de prueba que le permita anular el valor de Dependency antes de invocar métodos en ComponentToTest .

este es un error en ES6. por lo que en algún momento en el futuro, cuando los motores admitan módulos ES6 de forma nativa, será necesario reescribir sus pruebas.

Ah, bastante bien, lo dejaré entonces, ya que ese requisito es tangencial a este problema.

Alternativamente, puede hacer que su ComponentToTest acepte un argumento para Dependencia, y sus pruebas pueden pasar eso ...

Creo que esto es con lo que terminamos. Es bastante poco convincente tener que redefinir la API de una clase para hacerla comprobable, pero supongo que no es un problema exclusivo de TS en absoluto.

Gracias por los comentarios, @mhegazy

Me gustaría anular la verificación del tipo de argumento de una función.

Mi caso de uso es bastante simple, tengo una función como esta:

function isValidId(s: string): boolean {}

que comprueben si una cadena sigue alguna regla.
Se usa tanto internamente como para validar la entrada del usuario; me gustaría escribir pruebas para ver si devuelve false cuando el usuario inserta algo que no es una cadena.

Estrictamente hablando, la función puede aceptar cualquier cosa como entrada porque es capaz de administrarla, pero como la usamos también internamente, me gustaría especificar que queremos una cadena

Por lo tanto, me gustaría algo para suprimir el error sobre el formato incorrecto en las pruebas.

@rpadovani solo usa any :

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

Yo también podría usar esto. Tenemos una situación en la que foo (bar: any, baz: any) se define como parte de un marco, pero en algunas implementaciones de foo, bar no se usa. Con la verificación de errores de mecanografiado activada, esto arroja un error porque se declara una variable no utilizada. Debe declararse, porque se utilizan otras versiones de foo, bar.

@benjaminabbitt Parece que foo (_bar: any, baz: any) funciona para usted: un nombre que comience con "_" no está obligado a usar.

Agregar: Creo que la capacidad de anular / ignorar errores especiales es importante.

Algo desafiante aquí es que la gente sigue apareciendo diciendo que quiere suprimir errores, publicar fragmentos de código y obtener soluciones efectivas en el código para silenciar esos errores (o descubrir que su código realmente tiene un problema). Es difícil diseñar esta función sin saber cómo se ve un error realmente problemático o sin comprender qué errores la gente quiere eliminar a nivel mundial.

¿Cuál es la forma adecuada de manejar el código javascript de terceros que deseamos incluir en nuestros proyectos?

Considere el siguiente escenario. Hay una biblioteca enorme que no se ha publicado en npm e incluso si lo fuera, usar la biblioteca tal como está haría que nuestra aplicación lleve una gran cantidad de código muerto (la agitación de árboles no puede ayudar porque adjuntan todo a un objeto).

Supongamos que en este caso no vale la pena extraer este fragmento de código y publicarlo en npm. ¿Qué otras opciones tenemos?

En mi intento de usar esta biblioteca, extraje el código que necesita mi proyecto y lo incorporé al proyecto como un archivo mecanografiado. El problema con esto es que mecanografiado comprueba este archivo y ahora da muchos errores para este archivo.

Para esta situación, sería genial tener el comentario /* ts:disable */ en la parte superior para que el mecanografiado sepa que no nos preocupan los posibles errores dentro del archivo.

Tenga en cuenta que mi proyecto ya no confirma ningún archivo javascript e incluso si lo hiciera, el proceso de compilación se volvería más complicado al intentar acomodar un javascript en el flujo.

¿Alguien tiene algún consejo sobre cómo lidiar con el código javascript de terceros que debe alojarse en un proyecto mecanografiado?

¿Alguien tiene algún consejo sobre cómo lidiar con el código JavaScript de terceros que debe alojarse en un proyecto mecanografiado?

no los migre. deje los archivos .js como están. cree un archivo .d.ts para ellos. esto es lo que son los archivos .d.ts de todas formas.

el archivo .d.ts puede comenzar con algo tan básico como:

declare var $: any;

luego agréguelo como mejor le parezca y a medida que sus necesidades crezcan.

Esa es una buena opción si estuviera confirmando archivos js. ¿Hay otras opciones para proyectos que ignoran los archivos js?

Esa es una buena opción si estuviera confirmando archivos js. ¿Hay otras opciones para proyectos que ignoran los archivos js?

No estoy seguro de haber entendido la pregunta. Los archivos JS se ignoran de forma predeterminada. por lo que opta por agregar archivos. de nuevo, mi recomendación es que, para el código externo que no es suyo, o para el código heredado que no tiene la intención de cambiar, no se moleste en convertirlo a TS. comience escribiendo un archivo .d.ts para ellos. para esto, comience simple, con any y luego agregue sobre la marcha.

Debería haber dicho que los archivos js no se están comprometiendo con el repositorio de git, de ahí la razón de poner el código en un archivo ts. De todos modos, intentaré seguir la ruta que mencionaste y forzar la confirmación de esos archivos js.

no es necesario que confirme los archivos .js. digamos que está usando una dependencia, digamos reaccionar. por lo general, no enviará react-0.12.0.js en su repositorio, pero desea usarlo. Normalmente, incluiría esto en una etiqueta sccript de un CDN, por ejemplo. digamos también que @types/react no existe, o no desea utilizarlo. así que en su proyecto agregue un nuevo archivo de declaración llámelo declarations.d.ts y agregue:

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

esto le dice al compilador que hay un módulo llamado "react" y que solo lo usará, sin necesidad de incluir ningún archivo .js.

Entonces, si quiero usar una pequeña parte de javascript (que no está disponible a través de npm / CDN) y decido enviarlo a mi base de código, tengo 2 opciones:

Opción 1 : Mantenga el código original como un archivo .js y mantenga un archivo .d.ts para manejar tipos.

Creo que esto no funciona para @ jmlopez-rod porque no quiere enviar código javascript a su repositorio, e incluso si lo hiciera, dijo que complicaría su proceso de compilación.

Opción 2 : Envuelva el javascript en mecanografiado y trate con todos los errores de mecanografiado.

Esto evita el "complicado proceso de compilación" porque tratará el código como si fuera mecanografiado ... pero ahora tenemos errores de mecanografiado y hemos vuelto a la discusión original en este tema. ¿Es este un caso de uso válido para poder deshabilitar los errores de mecanografía?

Creo que esto no funciona para @ jmlopez-rod porque no quiere enviar código javascript a su repositorio, e incluso si lo hiciera, dijo que complicaría su proceso de compilación.

No estoy seguro de entender por qué complica su proceso de construcción. tiene un archivo "library.js" y "website.js" , decide mover "website.js" a "website.ts", simplemente llame a tsc website.ts --outFile website.js y ahora estamos de vuelta donde todo comenzó con dos archivos .js. así que no veo por qué es más complicado que antes ... es solo un paso adicional de construcción en la cabeza de la cadena.

Esto evita el "complicado proceso de compilación" porque tratará el código como si fuera mecanografiado ... pero ahora tenemos errores de mecanografiado y hemos vuelto a la discusión original en este tema. ¿Es este un caso de uso válido para poder deshabilitar los errores de mecanografía?

No estoy seguro de entender completamente por qué decidió cambiar este archivo a ts e integrarlo con su proyecto, dejar que los tipos fluyan a sus otros componentes, compilarlo junto con su código, pero mantenerlo en un estándar diferente.

Puede ser un ejemplo que sería útil aquí. como señaló @RyanCavanaugh , me parece que todos estos problemas tienen formas bien definidas de informar al compilador sobre los tipos y evitar errores en lugar de deshabilitarlos todos juntos y arrojar al bebé con el agua de la bañera.

No pude entender por qué esta declaración ambiental no funciona para mí.
Ya definí la definición de rutas al tsconfig.json así
"paths": { "js-xlsx": ["./xlsx.d.ts"] }
pero todavía me encuentro con ese error de módulo no encontrado.
Intenté agregar 'fs', 'fs-extra' y las bibliotecas 'js-xlsx' no respondieron a mis declaraciones ambientales, castings o agregar ningún tipo como aquí declare var $: any;
@mhegazy

no es necesario que confirme los archivos .js. digamos que está usando una dependencia, digamos reaccionar. por lo general, no confirmará react-0.12.0.js en su repositorio, pero desea usarlo. Normalmente, incluiría esto en una etiqueta sccript de un CDN, por ejemplo. digamos también que @ types / react no existe, o no quieres usarlo. así que en su proyecto agregue un nuevo archivo de declaración llámelo declarations.d.ts y agregue:

declarar módulo "reaccionar"; // simplemente diciendo que el módulo es de tipo any
esto le dice al compilador que hay un módulo llamado "react" y que solo lo usará, sin necesidad de incluir ningún archivo .js.

Por cierto, sé que la biblioteca fs-extra tiene la definición de tipo como @ types / fs-extra y para js-xlsx tenemos bibliotecas ts-xlsx, pero esto es tan extraño que estos trucos no funcionan para mí :(

Por cierto, sé que la biblioteca fs-extra tiene la definición de tipo como @ types / fs-extra y para js-xlsx tenemos bibliotecas ts-xlsx, pero esto es tan extraño que estos trucos no funcionan para mí :(

Creo que hay algo más en su proyecto.

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

sí, tal vez, pero el problema principal que no pude entender es por qué no pude suprimir las advertencias del compilador con los métodos dados. Por cierto tengo https://github.com/AngularClass/angular2-webpack-starter , base para mi proyecto

Suprimir errores no significa necesariamente introducir antipatrones.

Recibo un error incorrecto

error TS1005: '{' expected.

en este JSX perfectamente bien:

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

Se queja de que la cadena de la plantilla necesita { . Idealmente, esto debería arreglarse, pero hasta entonces, me gustaría poder suprimir el error por una buena razón .

@trusktr , este error es un error de análisis. suprimirlo no cambia el hecho de que el compilador no comprende el código a partir de este momento, y la forma del resto del archivo está en un estado indefinido. eso quiere decir que aunque este error sea amortiguado, los tipos inferidos, así como otros errores generados en este archivo u otros no son correctos.

Dicho eso. Según la especificación JSX :

JSXAttributeValue:

"JSXDoubleStringCharactersopt"
'JSXSingleStringCharactersopt'
{AssignmentExpression}
JSXElement

Así que me temo que el error es correcto y un atributo JSX no puede tener un literal de plantilla de cadena. puedes usar absolteSize = {...} lugar

este error es un error de análisis

Sí, es por eso que debería arreglarse.

La salida es absoluteSize: "0, " + this.MENU_BAR_HEIGHT + ", 0" , lo que me dice que el compilador está bien.

Oh. Perdón entonces. Echo de menos entendido tu comentario. Pensé que querías silenciar el error.

Lo hice, pero tienes razón, tal vez debería vivir mejor con solo agregar {} .

En TS 2.1 (VS2017 RC) recibimos advertencias informadas provenientes de bibliotecas archivos JS (ubicados en la carpeta / Scripts), como TS7027. Sería bueno poder suprimir advertencias / errores de los archivos de la biblioteca o al menos suprimirlos en algún tipo de archivo de supresión global (similar a C # GlobalSupressions.cs)

En TS 2.1 (VS2017 RC) recibimos advertencias informadas provenientes de bibliotecas archivos JS (ubicados en la carpeta / Scripts), como TS7027.

Para el código inalcanzable (TS 7027), configure --allowUnreachableCode o configúrelo en su tsconfig.json .

Pero, ¿es posible aplicarlo solo a archivos de biblioteca? ¡Porque para "mi código" lo necesito!

al usar --alowJs se convierte en su código. el compilador lo absorberá, lo transpilará al objetivo sugerido, lo concatenará si usa --outFile .. solo que tiene una extensión .js. si se trata de un código de "biblioteca", recomendaría crear un .d.ts para él e incluirlo en su lugar.

No sé que hayamos activado --allowJs - en VS2015, exactamente el mismo proyecto no garabatea los archivos jquery.js, react.js que se encuentran en Scripts (y de hecho se hace referencia solo desde la 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);
});

En mi caso, la primera línea escrita en TypeScript, la segunda línea escrita en JavaScript. Se ejecutan en diferentes contextos y no quiero modificar el código JavaScript.
Entonces, necesitamos una nueva opción como /* ts-disable */ /* ts-enable */ (eslint-like)

En mi caso, la primera línea escrita en TypeScript, la segunda línea escrita en JavaScript. Se ejecutan en diferentes contextos y no quiero modificar el código JavaScript.

¿No estoy seguro de entender lo que quiere decir con "segunda línea escrita en JavaScript"? ¿Pasas la declaración completa al compilador o no?

¿No estoy seguro de entender lo que quiere decir con "segunda línea escrita en JavaScript"? ¿Pasas la declaración completa al compilador o no?

No quiero modificar ese código porque debería pasarse al servidor Selenium tal cual .

No quiero modificar ese código porque debería pasarse al servidor Selenium tal cual.

si está en un archivo .ts, el compilador lo transformará. El compilador elimina las anotaciones de tipo por usted.

Independientemente, para esta muestra, todo lo que necesita es declare var browser: any; y no debería recibir ningún error. consulte Zona de

si está en un archivo .ts, el compilador lo transformará. El compilador elimina las anotaciones de tipo por usted.

Necesito una garantía de que un código dado se ha ejecutado sin alteraciones en IE6 y otros navegadores antiguos.
Por ejemplo, Node.js sigue el sistema de módulos CommonJS, pero mi require es una función personalizada definida por otros desarrolladores en sus páginas. Es por eso que me gustaría incluir ese código sin modificaciones posteriores ni previas. Es importante para mí y para mi equipo.

Independientemente, para esta muestra, todo lo que necesita es declarar var browser: any; y no debería recibir ningún error. consulte Zona de juegos para ver una muestra.

En realidad, el objeto del navegador es el objeto más popular de mi proyecto y no hay ninguna razón para ignorarlo. El método browser.execute tiene su propia declaración de tipo.

ahora no estoy seguro de entender cuál es el problema. ¿Cuál es el error que está recibiendo?

Mi código se ejecuta en diferentes contextos: nodo y navegador. Los problemas actuales para el segundo contexto son las anotaciones de tipo y la modificación del 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); 
});

Aquí hay una implementación simple del método browser.executeAsync :

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

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

Como puede ver, uso TypeScript para las pruebas de integración.

¿Cuál es el mensaje de error?

Errores estándar:

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

Etcétera...

Defina require correctamente.

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

Defina require correctamente.

No puedo. En mi caso, el método executeAsync contiene código para proyectos de terceros y existen diferentes variaciones para tales require s. El código anterior es solo una función de cientos.
Mi deseo es muy simple: permítame excluir algún código cuando lo necesite :)

puede poner declare function require(v: string[]): any; localmente. p.ej:

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

también puede enviar a any cuando sea necesario:

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

Esto debería producir un código idéntico.

En mi caso, tengo una clase abstracta privada (no exportada) que solo debe extenderse por dos clases:

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

Pero en el método fromConfig() obtengo "No se puede crear una instancia de la clase abstracta 'Padre':

Código del patio de recreo

• Puedo duplicar los métodos estáticos y hacer que llamen a una función común, pero suena bastante estúpido cuando ya tengo un código de trabajo.
• No puedo hacer que la clase no sea abstracta porque las subclases aplican la implementación del método.
• Puedo eliminar los métodos abstractos pero los uso para aplicar la misma interfaz en subclases.
• Puedo usar una interfaz separada para hacerla cumplir, pero luego la superclase no se ajustará a la interfaz y es el tipo devuelto por el método estático.
• No tengo la intención de llamar al método estático en la clase abstracta, solo quiero que cree una instancia de una clase diferente en las diferentes subclases

El compilador no exige que los constructores de clases derivadas tengan la misma firma que la base. en otras palabras, el constructor de la clase derivada puede tener más argumentos requeridos que la base. el uso de new this() supone que todos los constructores derivados no tendrán parámetros obligatorios; y eso es algo no comprobable.

Si está seguro de que esto es correcto, considere enviarlo como new (<any>this)(x, y);

Buen punto, no vi eso. Tu sugerencia realmente funciona, consideraré los peligros, gracias.

¿Hay alguna forma de silenciar el Module ... was resolved to ..., but '--allowJs' is not set ? en mi caso de uso, hay un sistema de compilación que se encarga de eso y no necesito pasar todo mi código a través de TSC, así que me gustaría silenciar esos errores.

'declarar módulo "someModule";' en uno de sus archivos .d.ts.

O instale el paquete @types correspondiente, si existe.

Tengo otro ejemplo de cuando esto sería ú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>
);

Esto arroja un error porque onTouchStart no acepta una cadena como parámetro que es verdadero. Sin embargo, onTouchStart='' corrige el comportamiento de CSS roto en dispositivos táctiles relacionado con ciertas reglas de CSS. No me gustaría deshabilitar este error globalmente o redefinir algunos tipos de JSX. Me gustaría en esta línea eliminar este error.

onTouchStart={<any>''}

Eso en realidad no lo soluciona.
Me sale este error:

Está roto bajo la sintaxis tsx

onTouchStart={'' as any} , más bien (olvidé que JSX usa una sintaxis de aserción alternativa)

¿@RyanCavanaugh calificaría el código generado como un caso de uso legítimo para esta función? Estoy usando swagger codegen para crear un cliente api para un servicio de nodo. También estoy usando los tipos de cliente generados en mi servidor, ya que transforma las definiciones de fanfarronería en interfaces TypeScript, por lo que es la forma más fácil de asegurarme de que estoy respetando mi propio contrato de fanfarronería.

Sin embargo, el código generado es un poco extraño y tiene bloques como este:

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

Esto da un error si strictNullChecks está activado, así que desactivé la bandera para todo el proyecto. Lo que apesta. No quiero analizar el mecanografiado generado y modificarlo, pero estaría preparado para insertar algo como <tsc strictNullChecks=false /> en la parte superior del archivo (similar a la sugerencia de @alexanderbird ).

¿No sería esta una solicitud de cambio al generador de código swagger para producir un código estricto compatible con NullChecks?

@mhegazy seguro, pero este es solo un ejemplo de algo como esto. Hay muchas formas en que la generación de código es útil en TypeScript (más que en JavaScript). Entonces, idealmente, habría una manera de no obligar a las personas a arrastrar sus propios proyectos a los estándares de su código generado.

Pero son :) el código que obtiene de su herramienta de generación automática da como resultado tipos que fluyen en su compilación. si la herramienta de generación de código ignora --strictNullChecks entonces su código está observando tipos no engañosos.
deshabilitar los controles es simplemente amortiguar la alarma de incendio. el problema no es la alarma, es lo que está causando el incendio en primer lugar.

@mhegazy Estoy de acuerdo con silenciar la alarma de incendio en un código generado por una herramienta muy probada. El código es bueno, simplemente no están usando características de lenguaje de última generación y no deberían tener que hacerlo.

¿Qué tal un ejemplo menos controvertido? ¿Qué pasa si el código generado tiene un local no utilizado? Eso no causa ningún daño a mi código, excepto en el caso de que tenga que desactivar noUnusedLocals en tsconfig, que es lo que estoy haciendo ahora.

¿Qué tal un ejemplo menos controvertido? ¿Qué pasa si el código generado tiene un local no utilizado? Eso no causa ningún daño a mi código, excepto en el caso de que tenga que desactivar noUnusedLocals en tsconfig, que es lo que estoy haciendo ahora.

si no le importa el código generado, entonces debería estar en .js con un .d.ts complementario. de esta forma puede comprobarlo, pero no tiene que compilarlo.

al compilador de mecanografiado no parece gustarle los mixins de underscore.js usados ​​con chain.

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

....

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

...

Un ejemplo bastante sencillo es cuando crea un oyente para hacer clic, por ejemplo con @HostListener() para Angular, así:

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

Si habilito noUnusedLocals , tengo el siguiente error:

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

¿De alguna manera puedo dejar que el compilador ignore eso?

@JeremyCarlsten

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

parece un código no válido.

@leocaseiro ¿Por qué debe ser privado? En este caso onClick es un método que angular terminará usando. Siempre ocurre un problema similar cuando declaramos variables privadas que usamos en una plantilla. Si los usa en la plantilla, simplemente haga públicas las variables. Tiene sentido ya que está permitiendo que angular los use.

Hola @ jmlopez-rod, tienes razón.

Interesante que como público, ¡ya está pasando! Realmente aprecio tu ayuda.

@leocaseiro public es el nivel de visibilidad predeterminado, por lo que no es necesario especificarlo.

Disculpe de antemano si suena negativo, es posible que me haya perdido algo (nuevo en TS).
Otro ejemplo (solo estoy usando TS para producir ES5, sin casting, declaración, interfaz)

// 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;
}

cierto en el momento de la creación, pero no cuando se usa, ¡no me MAMÁ!

Eso es específicamente para lo que TypeScript está diseñado. Si no desea utilizar tipos y conversión, ¿por qué utiliza TypeScript? Como se señaló varias veces en este hilo, aún emitirá el código, por lo que ya ignora los errores bajo su propio riesgo. ¿Por qué tratar de simplificar TypeScript, con qué propósito?

¿Por qué tratar de simplificar TypeScript, con qué propósito?

Se trata de mover un equipo de ES5 => ES6 (Babel o TS) => TS en todo su esplendor, en pequeños pasos.

Mi impresión fue que TS es una adición a JS que le permite intervenir en el nivel en el que se encuentra.
El motivo de mi queja es que el ejemplo ficticio proporcionado arroja un error y, por lo tanto, _does
no producir ES5_. En mi opinión, no debería ser obligatorio traspilar pelusa de paso.

A menos que no haya emitido por error, emitirá. Entonces produce ES5.

No lo hizo, cambió a Babel, funcionó

tsc se puede configurar para emitir la salida independientemente de los errores de tipo, mire la opción noEmitOnError .

Si está usando ts-loader, también tiene una nueva opción transpileOnly donde simplemente se transpilará y no mostrará ningún error.

@trusktr gracias, lo intentaré :-)

los errores no bloquean la generación de salidas, ni el herramental

Eso no es cierto. Tenemos una configuración (bastante común, proviene de un iniciador) en el paquete web que en la compilación de producción falla y NO genera nada. Y debería ser así: el compilador informa de errores, el programador retrocede y los corrige. ¿Por qué usar tipos cuando todo el equipo los ignora porque la construcción está "funcionando"? De manera similar, si tsc no se compila, la actualización automática no funciona (el complemento se escribe intencionalmente de esa manera; no se actualiza si su código es incorrecto [o el compilador lo considera incorrecto]).

La supresión de errores es útil cuando hay un error en tsc. Por ejemplo, esto debería compilar:

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

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

pero en la versión actual de TS falla.

Editar: llamada de función fija (línea incorrecta copiada)

Por

a.isEmptyObject ({a: 1});

Quiere decir

a.isEmpty ({a: 1});

?

Oh si. Línea incorrecta copiada: /.

La supresión de errores es útil cuando hay un error en tsc.

Se debe corregir un error que evita la emisión. Es muy poco probable que la capacidad de ignorar un error haga que tsc emita algo repentinamente cuando tiene un error que lo hace fallar.

Tengo una importación que se parece a esto:

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

Primero uso TypeScript, luego Babel. Tengo un complemento de babel que trata * en las importaciones como un patrón global. TypeScript arroja un error quejándose de .ts , y luego, si se elimina .ts no puede encontrar el módulo.

No estoy realmente seguro de cómo resolver esto, pero mi primer pensamiento fue suprimir los errores relacionados con esta línea. Intenté hacer un mapeo de módulos en la configuración, pero * se trata como un comodín allí y no se puede escapar.

@lukescott en un .d.ts dentro del alcance del compilador:

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

Otro ejemplo de cómo esto sería útil:

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

El getPeerCertificate dice que no existe debido a definiciones defectuosas en el nodo https ( también esto ).

Todavía se compila y funciona con el subrayado rojo grande, pero sería muy bueno hacerlo

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

@trusktr
Vaya, parece que arruiné la sintaxis convirtiéndolo del código de producción. Aquí hay un fragmento js de lo que estaba tratando de describir. Quizás sea más un problema con las definiciones de subrayado. Pero si una biblioteca de terceros está causando problemas con el compilador ts, ¿no deberíamos poder ignorar esa línea de código?

+1. Esto será útil para las pruebas, ya que necesito asegurarme de que mi código arroje un error cuando se pasa en algo que no se espera.

Esta característica útil sería simplemente la generalización de ! para objetos posiblemente nulos.

Si quiero traer un archivo de biblioteca a un proyecto (por ejemplo, Chartjs), a menudo lo guardo como un archivo TS (me gusta mantener todos los archivos fuente como TS y compilados como JS) e importarlo con una referencia de barra diagonal triple en el TS archivo que lo requiera. Sin embargo, TypeScript se queja interminablemente de los errores en ese archivo (naturalmente, ya que es simplemente un archivo JS estándar guardado como TS).

Sin embargo, la capacidad de agregar:

/*ts-errors-disable*/ al comienzo del archivo de la biblioteca y /*ts-errors-enable*/ al final reduciría la salida de errores que no son relevantes pero que aún así permitirían a los desarrolladores mantener todos los archivos fuente como TS.

¿O debería hacer las cosas de manera fundamentalmente diferente?

@benfrain Bueno, sería mejor instalar el archivo de definiciones de TypeScript correspondiente si existe ( npm install --save-dev @types/mylibrary ) o crear su propio archivo _.d.ts_ con un tipo any en el espacio de nombres de su biblioteca / clase principal primero:

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

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

Tengo una pregunta. Primero el código y el error que destaca TypeScript:

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, '')
  }
}

El problema que tengo es que necesito declarar el decorador @Input para permitir que el atributo pase una cadena. Pero solo me importa el valor de esa cadena cuando cambia. Y puedo obtener el valor anterior y actual al manejar el evento de cambio.

¿Podemos tener un // ts-ignore ahora? ¿O hay otra forma de resolver esto bien?

@uglow ¿ attrName privado? Esta es una variable que Angular modifica para que pueda obtener un valor con ella. Por lo tanto, debe ser público.

@ jmlopez-rod Lo cambié a público, pero eso no cambia el problema. TS está diciendo que es una variable no utilizada.

Estoy usando TS 2.4.1, después de hacerlo público, el mecanografiado deja de emitir el error.

Antes:

Después:

Estoy usando 2.3.3. Le daré una oportunidad a 2.4.1. Gracias 😊

Esto debería incluirse. Estoy trabajando con un motor js personalizado que permite que un solo archivo .js devuelva un valor. Vea mi esencia para un ejemplo . Utilizo TS para generar mis archivos .js y, por supuesto, TS no lo sabe y arroja:

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

Una nueva pregunta SO que debe suprimir el error noUnusedLocals :
https://stackoverflow.com/questions/45519476/is-it-a-typescript-antipattern-to-dynamically-call-a-member-function-stored-in-a

@mhegazy He enfrentado este tipo de problema de diferentes maneras.

Mi situación actual (todo el flujo asume el modo de declaración):

• los decoradores de clases requieren una declaración de clase (no una expresión de clase) y estoy dentro de una función; en principio, esto podría arreglarse, pero no lo es hoy.
• ok, no hay problema, haré de la expresión una declaración
• sin dados, la declaración ahora tiene un nombre sin usar
• ok no hay problema te lo devuelvo
• sin dados, Return type of public method from exported class has or is using private name
• ...?

Básicamente, la causa principal aquí es que las expresiones no se pueden decorar, pero no es razonable que deje todo para implementar esa funcionalidad. Mientras tanto, es sensato para mí simplemente suprimir este error. Estaría bien si suprimir un error requiriera que encontrara el problema TypeScript asociado y dijera algo como // TS-LIMITATION:#9448 aunque sospecho que eso resultaría en una gran cantidad de nuevos problemas inútiles desde su perspectiva.

Incluso estaría bien si agregara supresiones dirigidas específicas para problemas conocidos que aún no está listo para abordar, pero solo si eso se hizo rápidamente y sin demasiado esfuerzo de diseño (eso haría que el mecanismo no tuviera sentido: guiño :)

No quiero obtener un error de código inalcanzable (donde estoy feliz de anotar "Cállate ante el error de código inalcanzable aquí mismo") cuando hago algo como
if (false){ ...complicated debug code that I dont want to delete/forget... }

Por lo tanto, al compilador de TypeScript todavía le falta una opción para "callarse y no estropear otras herramientas". Sería realmente útil para nosotros tener esta opción a través de comentarios y mediante conmutadores del compilador para archivos específicos o incluso glob. Estamos atascados en el uso de versiones antiguas de herramientas porque no queremos perder la recarga automática (las versiones más nuevas no se recargan automáticamente cuando hay errores). Entonces, o desactivamos la opción con errores noImplicitAny (que realmente no quiero, estoy usando TypeScript debido a la verificación de tipos y con el implícito permitido, cualquier TypeScript no aporta tanto a una tabla) o nos quedamos en versiones antiguas de paquetes. Sí, me informó del fallo tanto, WebPack y AwesomeTypeScript cargador, pero a nadie le importa. El problema se está ignorando desde hace muchos meses. Veo que es exactamente lo mismo con el paquete TypeScript :-(.

@polyglotinc if (!!false) {

@RyanCavanaugh Bueno, para el caso, (!true) funciona ... Ni siquiera pensé en esas como posibilidades porque yo _ (como ex-compilador-escritor) _ le di más crédito al compilador con respecto a constante / literal expresión colapsando ... Supongo que pensé que si iba a ser un cuerpo ocupado sobre if (false) , ¡sabría que if (!true) era lo mismo!

@unional, la pregunta SO podría escribirse un poco más clara y quizás es por eso que necesitamos que el compilador nos informe sobre posibles errores. Vea esta captura de pantalla que muestra el error que el usuario quiere eliminar.

Observe que en la captura de pantalla solo tengo un error. Eso es porque ya solucioné un problema detectado por el compilador.

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

El usuario afirma que se están utilizando handleArrow* pero el mecanografiado no ve que se esté utilizando. En lo que respecta al mecanografiado, this en this.handleArrowDown($event); podría ser cualquier objeto que tenga el método handleArrowDown . Con la función de flecha ahora sabe que this es la instancia de la clase y, por lo tanto, ve que se está utilizando handleArrowUp .

Otra opción: use el primer parámetro falso this .

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

@ jmlopez-rod Gracias. Éstas son una buena alternativa. Me gusta especialmente la solución function(this: SomeComponent, ...) {...} porque es la más flexible.

La función de flecha no funciona si keyHandlers no es parte de la clase:

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 otro lado, la función de flecha es la más sencilla en este contexto.

Estoy tratando de configurar manualmente window.console para IE9 para evitar errores en el uso de console.log :

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

Pero obtengo error TS2540: Cannot assign to 'console' because it is a constant or a read-only property. ¿Existe alguna solución para estos casos de uso?

@amiraliakbari Puede afirmar window como any type, lo que efectivamente le permite optar por no participar en las verificaciones de tipo:

(window as any).console = {};

esto funcionó para mí para anular / deshabilitar console.log globalmente: tenga en cuenta que Project.logging se definió antes de esto

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

Esto también fue mucho más limpio que poner if declaraciones en todo mi código, ya que puedo usar console.log como de costumbre

Como se mencionó en # 19109, todavía no tenemos la capacidad de suprimir un error específico .

Como se mencionó en # 19109, todavía no tenemos la capacidad de suprimir un error específico.

Creo que se ha abordado el escenario básico descrito en este número. podemos crear un nuevo problema para rastrear la supresión de errores globales usando el número de error. Hemos sido reacios a usar códigos de error de esa manera porque carecen de expresividad.

Creado # 19139.

Esta instrucción funciona solo por archivo, ¿verdad? ¿Es posible hacer que funcione sobre una carpeta?

Se supone que la instrucción funciona para una sola línea a la vez. Si ve muchos errores del compilador en su proyecto, puede verificar que debe tener opciones de compilador menos estrictas, como dejar noImplicitAny desactivado (es decir, las variables son implícitamente any si no anotado). También puede dejar algunos archivos como JS y configurar allowJs pero checkJs desactivado.

¿Por qué cerró este problema? ¡Aún falta la solución! ¿Por qué tiene discusiones sin sentido durante 2 años en lugar de integrar una posibilidad adecuada de supresión de errores?

@ webia1 Puede que le interese el # 19139, que aún está abierto.

(Agregar este comentario aquí, ya que podría ser útil para aquellos que se topan con este problema, como lo hice yo)

Me encontré con https://github.com/Microsoft/TypeScript/pull/21602 y podría ser la solución.

Simplemente agregue // @ts-ignore a su código (o incluso // @ts-ignore <some code error> para ignorar solo el error especificado) .

¡Lo probé aquí con TypeScript 2.7.2 y funciona!

(o incluso // @ ts-ignorepara ignorar solo el error especificado).

21602 no se fusionó. No puede ignorar solo ciertos errores.

@RyanCavanaugh, ¡tienes razón! Actualicé mi comentario. ¡Gracias!

Llegó aquí buscando suprimir el error TS2339.

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