TypeScript afirma ser un lenguaje de programación fuertemente tipado construido sobre JavaScript, que proporciona mejores herramientas a cualquier escala. Sin embargo,   incluye   tipo, lo que a menudo puede colarse implícitamente en una base de código y provocar la pérdida de muchas de las ventajas de TypeScript. TypeScript any  Este artículo explora formas de tomar el control de   tipo en proyectos TypeScript. Prepárese para liberar el poder de TypeScript, logrando la máxima seguridad de tipos y mejorando la calidad del código. any  Desventajas de usar Any en TypeScript  TypeScript proporciona una variedad de herramientas adicionales para mejorar la experiencia y la productividad del desarrollador:  Ayuda a detectar errores en las primeras etapas de la etapa de desarrollo.  Ofrece un excelente autocompletado para editores de código e IDE.  Permite una refactorización sencilla de grandes bases de código a través de fantásticas herramientas de navegación de código y refactorización automática.  Simplifica la comprensión de una base de código al proporcionar semántica adicional y estructuras de datos explícitas a través de tipos.  Sin embargo, tan pronto como comience a utilizar   tipo en su código base, perderá todos los beneficios enumerados anteriormente.   tipo es una laguna peligrosa en el sistema de tipos, y su uso desactiva todas las capacidades de verificación de tipos, así como todas las herramientas que dependen de la verificación de tipos. Como resultado, se pierden todos los beneficios de TypeScript: se pasan por alto los errores, los editores de código se vuelven menos útiles y más. any any  Por ejemplo, considere el siguiente ejemplo:   function parse(data: any) { return data.split(''); } // Case 1 const res1 = parse(42); // ^ TypeError: data.split is not a function // Case 2 const res2 = parse('hello'); // ^ any  En el código anterior:  Se perderá la finalización automática dentro de la función   . Cuando escribes   en su editor, no recibirá sugerencias correctas sobre los métodos disponibles para   . parse data. data  En el primer caso, hay un   porque pasamos un número en lugar de una cadena. TypeScript no puede resaltar el error porque   deshabilita la verificación de tipos. TypeError: data.split is not a function any  En el segundo caso, la variable   también tiene el tipo   . Esto significa que un solo uso de   puede tener un efecto en cascada en una gran parte de una base de código. res2 any any  Usar   está bien sólo en casos extremos o para necesidades de creación de prototipos. En general, es mejor evitar el uso   para aprovechar TypeScript al máximo. any any  De dónde viene el tipo Any  Es importante conocer las fuentes de   tipo en una base de código porque escribir explícitamente   no es la única opción. A pesar de nuestros mejores esfuerzos para evitar el uso de   tipo, a veces puede colarse implícitamente en una base de código. any any any  Hay cuatro fuentes principales de   tipo en un código base: any  Opciones del compilador en tsconfig.  Biblioteca estándar de TypeScript.  Dependencias del proyecto.  Uso explícito de   en una base de código. any  Ya escribí artículos sobre   y   para los dos primeros puntos. Échales un vistazo si quieres mejorar la seguridad tipográfica en tus proyectos. Consideraciones clave en tsconfig Mejora de los tipos de biblioteca estándar  Esta vez, nos centraremos en las herramientas automáticas para controlar la apariencia de   tipo en una base de código. any  Etapa 1: uso de ESLint    es una popular herramienta de análisis estático utilizada por los desarrolladores web para garantizar las mejores prácticas y el formato del código. Se puede utilizar para aplicar estilos de codificación y encontrar código que no cumpla con ciertas pautas. ESLint  ESLint también se puede utilizar con proyectos TypeScript, gracias al complemento   . Lo más probable es que este complemento ya esté instalado en su proyecto. Pero si no, puedes seguir la   . Typesctipt-eslint guía oficial de introducción  La configuración más común para   es la siguiente: typescript-eslint   module.exports = { extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', root: true, };  Esta configuración permite   comprender TypeScript a nivel de sintaxis, lo que le permite escribir reglas de eslint simples que se aplican a tipos escritos manualmente en un código. Por ejemplo, puedes prohibir el uso explícito de   . eslint any  El ajuste preestablecido   contiene un conjunto cuidadosamente seleccionado de reglas ESLint destinadas a mejorar la corrección del código. Si bien se recomienda utilizar todo el ajuste preestablecido, para los fines de este artículo, nos centraremos únicamente en la regla   . recommended no-explicit-any  no-explícito-cualquiera  El modo estricto de TypeScript impide el uso de   implícito, pero no impide que   se utilice explícitamente. La regla   ayuda a prohibir la escritura manual   lugar de una base de código. any any no-explicit-any any   // ❌ Incorrect function loadPokemons(): any {} // ✅ Correct function loadPokemons(): unknown {} // ❌ Incorrect function parsePokemons(data: Response<any>): Array<Pokemon> {} // ✅ Correct function parsePokemons(data: Response<unknown>): Array<Pokemon> {} // ❌ Incorrect function reverse<T extends Array<any>>(array: T): T {} // ✅ Correct function reverse<T extends Array<unknown>>(array: T): T {}  El objetivo principal de esta regla es evitar el uso de   en todo el equipo. Esta es una forma de fortalecer el acuerdo del equipo de que se desaconseja el uso de   en el proyecto. any any  Este es un objetivo crucial porque incluso un solo uso de   puede tener un impacto en cascada en una parte importante del código base debido a   . Sin embargo, esto todavía está lejos de alcanzar la seguridad de tipo definitiva. any la inferencia de tipos  Por qué nada explícito no es suficiente  Aunque hemos tratado   utilizado explícitamente, todavía hay muchos   implícitos dentro de las dependencias de un proyecto, incluidos los paquetes npm y la biblioteca estándar de TypeScript. any any  Considere el siguiente código, que probablemente se verá en cualquier proyecto:   const response = await fetch('https://pokeapi.co/api/v2/pokemon'); const pokemons = await response.json(); // ^? any const settings = JSON.parse(localStorage.getItem('user-settings')); // ^? any  Tanto   variables como   recibieron implícitamente   tipo. Ni   ni el modo estricto de TypeScript nos avisarán en este caso. Aún no. pokemons settings any no-explicit-any  Esto sucede porque los tipos de   y   provienen de la biblioteca estándar de TypeScript, donde estos métodos tienen una anotación   explícita. Todavía podemos especificar manualmente un tipo mejor para nuestras variables, pero hay casi 1200 apariciones de   de ellas en la biblioteca estándar. Es casi imposible recordar todos los casos en los que   puede colarse en nuestro código base desde la biblioteca estándar. response.json() JSON.parse() any any any  Lo mismo ocurre con las dependencias externas. Hay muchas bibliotecas mal escritas en npm y la mayoría todavía está escrita en JavaScript. Como resultado, el uso de dichas bibliotecas puede generar fácilmente una gran cantidad de   implícito en el código base. any  Generalmente todavía existen muchas formas para que   pueda colarse en nuestro código. any  Etapa 2: Mejora de las capacidades de verificación de tipos  Idealmente, nos gustaría tener una configuración en TypeScript que haga que el compilador se queje de cualquier variable que haya recibido   tipo por cualquier motivo. Desafortunadamente, dicha configuración no existe actualmente y no se espera que se agregue. any  Podemos lograr este comportamiento utilizando el modo de verificación de tipo del complemento   . Este modo funciona junto con TypeScript para proporcionar información de tipo completa desde el compilador de TypeScript a las reglas de ESLint. Con esta información, es posible escribir reglas ESLint más complejas que esencialmente amplían las capacidades de verificación de tipos de TypeScript. Por ejemplo, una regla puede encontrar todas las variables con   tipo, independientemente de   se obtuvo. typescript-eslint any any  Para utilizar reglas con reconocimiento de tipos, debe ajustar ligeramente la configuración de ESLint:   module.exports = { extends: [ 'eslint:recommended', - 'plugin:@typescript-eslint/recommended', + 'plugin:@typescript-eslint/recommended-type-checked', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', + parserOptions: { + project: true, + tsconfigRootDir: __dirname, + }, root: true, };  Para habilitar la inferencia de tipos para   , agregue   a la configuración de ESLint. Luego, reemplace el ajuste preestablecido   con   . Este último ajuste preestablecido agrega alrededor de 17 nuevas y poderosas reglas. A los efectos de este artículo, nos centraremos en sólo cinco de ellos. typescript-eslint parserOptions recommended recommended-type-checked  ningún argumento inseguro  La regla   busca llamadas a funciones en las que se pasa una variable de tipo   como parámetro. Cuando esto sucede, se pierde la verificación de tipos y también se pierden todos los beneficios de la escritura segura. no-unsafe-argument any  Por ejemplo, consideremos una función   que requiere un objeto como parámetro. Supongamos que recibimos JSON, lo analizamos y obtenemos   tipo. saveForm any   // ❌ Incorrect function saveForm(values: FormValues) { console.log(values); } const formValues = JSON.parse(userInput); // ^? any saveForm(formValues); // ^ Unsafe argument of type `any` assigned // to a parameter of type `FormValues`.  Cuando llamamos a la función   con este parámetro, la regla   la marca como insegura y requiere que especifiquemos el tipo apropiado para la variable   . saveForm no-unsafe-argument value  Esta regla es lo suficientemente potente como para inspeccionar en profundidad las estructuras de datos anidadas dentro de los argumentos de una función. Por lo tanto, puede estar seguro de que pasar objetos como argumentos de función nunca contendrá datos sin tipo.   // ❌ Incorrect saveForm({ name: 'John', address: JSON.parse(addressJson), // ^ Unsafe assignment of an `any` value. });  La mejor manera de corregir el error es utilizar   de TypeScript o una biblioteca de validación como   o   . Por ejemplo, escribamos la función   que limita el tipo preciso de datos analizados. la reducción de tipos Zod Superstruct parseFormValues   // ✅ Correct function parseFormValues(data: unknown): FormValues { if ( typeof data === 'object' && data !== null && 'name' in data && typeof data['name'] === 'string' && 'address' in data && typeof data.address === 'string' ) { const { name, address } = data; return { name, address }; } throw new Error('Failed to parse form values'); } const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues saveForm(formValues);  Tenga en cuenta que está permitido pasar   tipo como argumento a una función que acepte   , ya que no existen problemas de seguridad asociados con hacerlo. any unknown  Escribir funciones de validación de datos puede ser una tarea tediosa, especialmente cuando se trata de grandes cantidades de datos. Por lo tanto, vale la pena considerar el uso de una biblioteca de validación de datos. Por ejemplo, con Zod, el código se vería así:   // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); const formValues = schema.parse(JSON.parse(userInput)); // ^? { name: string, address: string } saveForm(formValues);  no-asignación-insegura  La regla   busca asignaciones de variables en las que un valor tenga   tipo. Estas asignaciones pueden inducir a error al compilador haciéndole creer que una variable tiene un tipo determinado, mientras que los datos pueden tener en realidad un tipo diferente. no-unsafe-assignment any  Considere el ejemplo anterior de análisis JSON:   // ❌ Incorrect const formValues = JSON.parse(userInput); // ^ Unsafe assignment of an `any` value  Gracias a la regla   , podemos detectar   tipo incluso antes de pasar   a otra parte. La estrategia de fijación sigue siendo la misma: podemos utilizar la reducción de tipos para proporcionar un tipo específico al valor de la variable. no-unsafe-assignment any formValues   // ✅ Correct const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues  sin acceso-miembro-inseguro y sin-llamada-insegura  Estas dos reglas se activan con mucha menos frecuencia. Sin embargo, según mi experiencia, son realmente útiles cuando intentas utilizar dependencias de terceros mal escritas.  La regla   nos impide acceder a las propiedades del objeto si una variable tiene   tipo, ya que puede ser   o   . no-unsafe-member-access any null undefined  La regla   nos impide llamar a una variable con   tipo como función, ya que puede que no sea una función. no-unsafe-call any  Imaginemos que tenemos una biblioteca de terceros mal escrita llamada   : untyped-auth   // ❌ Incorrect import { authenticate } from 'untyped-auth'; // ^? any const userInfo = authenticate(); // ^? any ^ Unsafe call of an `any` typed value. console.log(userInfo.name); // ^ Unsafe member access .name on an `any` value.  El linter destaca dos cuestiones:  Llamar a la función   puede ser inseguro, ya que podemos olvidarnos de pasar argumentos importantes a la función. authenticate  Leer la propiedad   del objeto   no es seguro, ya que será   si falla la autenticación. name userInfo null  La mejor manera de corregir estos errores es considerar el uso de una biblioteca con una API fuertemente tipada. Pero si esto no es una opción, usted mismo puede  . Un ejemplo con los tipos de biblioteca fijos se vería así: aumentar los tipos de biblioteca   // ✅ Correct import { authenticate } from 'untyped-auth'; // ^? (login: string, password: string) => Promise<UserInfo | null> const userInfo = await authenticate('test', 'pwd'); // ^? UserInfo | null if (userInfo) { console.log(userInfo.name); }  sin retorno inseguro  La regla   ayuda a no devolver accidentalmente   tipo de una función que debería devolver algo más específico. Estos casos pueden inducir a error al compilador haciéndole creer que un valor devuelto tiene un tipo determinado, mientras que los datos pueden tener en realidad un tipo diferente. no-unsafe-return any  Por ejemplo, supongamos que tenemos una función que analiza JSON y devuelve un objeto con dos propiedades.   // ❌ Incorrect interface FormValues { name: string; address: string; } function parseForm(json: string): FormValues { return JSON.parse(json); // ^ Unsafe return of an `any` typed value. } const form = parseForm('null'); console.log(form.name); // ^ TypeError: Cannot read properties of null  La función   puede provocar errores de tiempo de ejecución en cualquier parte del programa donde se utilice, ya que el valor analizado no se verifica. La regla   evita estos problemas de tiempo de ejecución. parseForm no-unsafe-return  Solucionar esto es fácil agregando validación para garantizar que el JSON analizado coincida con el tipo esperado. Usemos la biblioteca Zod esta vez:   // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); function parseForm(json: string): FormValues { return schema.parse(JSON.parse(json)); }  Una nota sobre el rendimiento  El uso de reglas de verificación de tipos conlleva una penalización de rendimiento para ESLint, ya que debe invocar el compilador de TypeScript para inferir todos los tipos. Esta desaceleración se nota principalmente cuando se ejecuta linter en ganchos de confirmación previa y en CI, pero no se nota cuando se trabaja en un IDE. La verificación de tipos se realiza una vez al iniciar el IDE y luego actualiza los tipos a medida que cambia el código.  Vale la pena señalar que simplemente inferir los tipos funciona más rápido que la invocación habitual del compilador   . Por ejemplo, en nuestro proyecto más reciente con aproximadamente 1,5 millones de líneas de código TypeScript, la verificación de tipos a través   demora aproximadamente 11 minutos, mientras que el tiempo adicional requerido para que se inicien las reglas de reconocimiento de tipos de ESLint es de solo aproximadamente 2 minutos. tsc tsc  Para nuestro equipo, la seguridad adicional que proporciona el uso de reglas de análisis estático con reconocimiento de tipo vale la pena. En proyectos más pequeños, esta decisión es aún más fácil de tomar.  Conclusión  Controlar el uso de   en proyectos TypeScript es crucial para lograr una seguridad de tipos y una calidad del código óptimas. Al utilizar el complemento   , los desarrolladores pueden identificar y eliminar cualquier aparición de   tipo en su código base, lo que da como resultado un código base más sólido y fácil de mantener. any typescript-eslint any  Al utilizar reglas eslint con reconocimiento de tipos, cualquier aparición de la palabra clave   en nuestro código base será una decisión deliberada en lugar de un error o descuido. Este enfoque nos protege del   de nuestro propio código, así como de la biblioteca estándar y dependencias de terceros. any any  En general, un linter con reconocimiento de tipos nos permite alcanzar un nivel de seguridad de tipos similar al de los lenguajes de programación de tipos estáticos como Java, Go, Rust y otros. Esto simplifica enormemente el desarrollo y mantenimiento de grandes proyectos.  Espero que hayas aprendido algo nuevo de este artículo. ¡Gracias por leer!  Enlaces útiles   Biblioteca: mecanografiado-eslint   Artículo: Consideraciones clave en tsconfig   Artículo: Mejora de los tipos de biblioteca estándar   Documentos: Estrechamiento de tipos en TypeScript   Documentos: Inferencia de tipos en TypeScript   Biblioteca: Zod   Biblioteca: Superestructura

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Hacer que TypeScript sea verdaderamente "fuertemente tipificado"

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps