Si está creando aplicaciones web complejas, es probable que TypeScript sea su lenguaje de programación preferido. TypeScript es apreciado por su sólido sistema de tipos y sus capacidades de análisis estático, lo que lo convierte en una poderosa herramienta para garantizar que su código sea sólido y sin errores.  También acelera el proceso de desarrollo a través de la integración con editores de código, lo que permite a los desarrolladores navegar por el código de manera más eficiente y obtener sugerencias más precisas y finalización automática, además de permitir la refactorización segura de grandes cantidades de código.  El Compilador es el corazón de TypeScript, responsable de verificar la corrección de tipos y transformar el código TypeScript en JavaScript. Sin embargo, para utilizar completamente el poder de TypeScript, es importante configurar el Compilador correctamente.  Cada proyecto de TypeScript tiene uno o más archivos   que contienen todas las opciones de configuración del compilador. tsconfig.json  La configuración de tsconfig es un paso crucial para lograr una seguridad de tipos y una experiencia de desarrollador óptimas en sus proyectos de TypeScript. Al tomarse el tiempo para considerar cuidadosamente todos los factores clave involucrados, puede acelerar el proceso de desarrollo y garantizar que su código sea sólido y sin errores.  Desventajas de la configuración estándar  La configuración predeterminada en tsconfig puede hacer que los desarrolladores pierdan la mayoría de los beneficios de TypeScript. Esto se debe a que no habilita muchas capacidades potentes de verificación de tipos. Por configuración "predeterminada", me refiero a una configuración en la que no se establecen opciones del compilador de verificación de tipo.  Por ejemplo:   { "compilerOptions": { "target": "esnext", "module": "esnext", "esModuleInterop": true, "forceConsistentCasingInFileNames": true, "skipLibCheck": true, }, "include": ["src"] }  La ausencia de varias opciones de configuración clave puede resultar en una menor calidad del código por dos razones principales. En primer lugar, el compilador de TypeScript puede manejar incorrectamente tipos   e   en varios casos. null undefined  En segundo lugar,   tipo puede aparecer de forma incontrolable en su base de código, lo que lleva a la verificación de tipo deshabilitada en torno a este tipo. any  Afortunadamente, estos problemas son fáciles de solucionar ajustando algunas opciones en la configuración.  El modo estricto   { "compilerOptions": { "strict": true } }  El modo estricto es una opción de configuración esencial que proporciona garantías más sólidas de la corrección del programa al permitir una amplia gama de comportamientos de verificación de tipos.  Habilitar el modo estricto en el archivo tsconfig es un paso crucial para lograr la máxima seguridad de tipos y una mejor experiencia para los desarrolladores.  Requiere un poco de esfuerzo adicional para configurar tsconfig, pero puede ayudar mucho a mejorar la calidad de su proyecto.  La opción de compilador   habilita todas las opciones de la familia de modo estricto, que incluyen   ,   ,   , entre otros. strict noImplicitAny strictNullChecks strictFunctionTypes  Estas opciones también se pueden configurar por separado, pero no se recomienda desactivar ninguna de ellas. Veamos ejemplos para ver por qué.  Cualquier inferencia implícita   { "compilerOptions": { "noImplicitAny": true } }  El tipo   es una escapatoria peligrosa en el sistema de tipos estáticos, y su uso desactiva todas las reglas de verificación de tipos. Como resultado, se pierden todos los beneficios de TypeScript: se pierden errores, las sugerencias del editor de código dejan de funcionar correctamente, etc. any  Usar   está bien solo en casos extremos o para necesidades de creación de prototipos. A pesar de nuestros mejores esfuerzos,   tipo a veces puede infiltrarse implícitamente en una base de código. any any  Por defecto, el compilador nos perdona muchos errores a cambio de la aparición de   en un código base. Específicamente, TypeScript nos permite no especificar el tipo de variables, incluso cuando el tipo no se puede inferir automáticamente. any  El problema es que podemos olvidarnos accidentalmente de especificar el tipo de una variable, por ejemplo, a un argumento de función. En lugar de mostrar un error, TypeScript deducirá automáticamente el tipo de la variable como   . any   function parse(str) { // ^? any return str.split(''); } // TypeError: str.split is not a function const res1 = parse(42); const res2 = parse('hello'); // ^? any  Habilitar la opción del compilador   hará que el compilador resalte todos los lugares donde el tipo de una variable se deduce automáticamente como   . En nuestro ejemplo, TypeScript nos pedirá que especifiquemos el tipo para el argumento de la función. noImplicitAny any   function parse(str) { // ^ Error: Parameter 'str' implicitly has an 'any' type. return str.split(''); }  Cuando especificamos el tipo, TypeScript detectará rápidamente el error de pasar un número a un parámetro de cadena. El valor de retorno de la función, almacenado en la variable   , también tendrá el tipo correcto. res2   function parse(str: string) { return str.split(''); } const res1 = parse(42); // ^ Error: Argument of type 'number' is not // assignable to parameter of type 'string' const res2 = parse('hello'); // ^? string[]  Tipo desconocido en variables de captura   { "compilerOptions": { "useUnknownInCatchVariables": true } }  La configuración de   permite el manejo seguro de excepciones en bloques try-catch. De forma predeterminada, TypeScript asume que el tipo de error en un bloque catch es   , lo que nos permite hacer cualquier cosa con el error. useUnknownInCatchVariables any  Por ejemplo, podríamos pasar el error detectado tal cual a una función de registro que acepta una instancia de   . Error   function logError(err: Error) { // ... } try { return JSON.parse(userInput); } catch (err) { // ^? any logError(err); }  Sin embargo, en realidad, no hay garantías sobre el tipo de error y solo podemos determinar su verdadero tipo en tiempo de ejecución cuando ocurre el error. Si la función de registro recibe algo que no es un   , se producirá un error de tiempo de ejecución. Error  Por lo tanto, la opción   cambia el tipo de error de   a   para recordarnos que verifiquemos el tipo de error antes de hacer algo con él. useUnknownInCatchVariables any unknown   try { return JSON.parse(userInput); } catch (err) { // ^? unknown // Now we need to check the type of the value if (err instanceof Error) { logError(err); } else { logError(new Error('Unknown Error')); } }  Ahora, TypeScript nos pedirá que verifiquemos el tipo de la variable   antes de pasarla a la función   , lo que dará como resultado un código más correcto y seguro. Desafortunadamente, esta opción no ayuda con los errores de tipeo en las funciones   o las funciones de devolución de llamada. err logError promise.catch()  Pero discutiremos formas de lidiar con   en tales casos en el próximo artículo. any  Comprobación de tipos para los métodos Call y Apply   { "compilerOptions": { "strictBindCallApply": true } }  Otra opción corrige la apariencia de   llamada en función a través de   and   . Este es un caso menos común que los dos primeros, pero aún así es importante tenerlo en cuenta. De forma predeterminada, TypeScript no verifica los tipos en tales construcciones. any call apply  Por ejemplo, podemos pasar cualquier cosa como argumento a una función y, al final, siempre recibiremos el tipo   . any   function parse(value: string) { return parseInt(value, 10); } const n1 = parse.call(undefined, '10'); // ^? any const n2 = parse.call(undefined, false); // ^? any  Habilitar la opción   hace que TypeScript sea más inteligente, por lo que el tipo de devolución se deducirá correctamente como   . Y cuando intente pasar un argumento del tipo incorrecto, TypeScript señalará el error. strictBindCallApply number   function parse(value: string) { return parseInt(value, 10); } const n1 = parse.call(undefined, '10'); // ^? number const n2 = parse.call(undefined, false); // ^ Argument of type 'boolean' is not // assignable to parameter of type 'string'.  Tipos estrictos para el contexto de ejecución   { "compilerOptions": { "noImplicitThis": true } }  La siguiente opción que puede ayudar a prevenir la aparición de   en su proyecto corrige el manejo del contexto de ejecución en las llamadas a funciones. La naturaleza dinámica de JavaScript dificulta la determinación estática del tipo de contexto dentro de una función. any  De forma predeterminada, TypeScript usa el tipo   para el contexto en tales casos y no proporciona ninguna advertencia. any   class Person { private name: string; constructor(name: string) { this.name = name; } getName() { return function () { return this.name; // ^ 'this' implicitly has type 'any' because // it does not have a type annotation. }; } }  Habilitar la opción del compilador   nos pedirá que especifiquemos explícitamente el tipo de contexto para una función. De esta forma, en el ejemplo anterior, podemos detectar el error de acceder al contexto de la función en lugar del campo   de la clase   . noImplicitThis name Person  Soporte nulo e indefinido en TypeScript   { "compilerOptions": { "strictNullChecks": true } }  A continuación, varias opciones que se incluyen en el modo   no dan como resultado   tipo que aparezca en la base de código. Sin embargo, hacen que el comportamiento del compilador de TS sea más estricto y permiten que se encuentren más errores durante el desarrollo. strict any  La primera de estas opciones corrige el manejo de   e   en TypeScript. De forma predeterminada, TypeScript asume que   e   son valores válidos para cualquier tipo, lo que puede generar errores de tiempo de ejecución inesperados. null undefined null undefined  Habilitar la opción del compilador   obliga al desarrollador a manejar explícitamente los casos en los que pueden ocurrir   e   . strictNullChecks null undefined  Por ejemplo, considere el siguiente código:   const users = [ { name: 'Oby', age: 12 }, { name: 'Heera', age: 32 }, ]; const loggedInUser = users.find(u => u.name === 'Max'); // ^? { name: string; age: number; } console.log(loggedInUser.age); // ^ TypeError: Cannot read properties of undefined  Este código se compilará sin errores, pero puede arrojar un error de tiempo de ejecución si el usuario con el nombre "Max" no existe en el sistema y   devuelve   . Para evitar esto, podemos habilitar la opción del compilador   . users.find() undefined strictNullChecks  Ahora, TypeScript nos obligará a manejar explícitamente la posibilidad de que   devuelva   o   . users.find() null undefined   const loggedInUser = users.find(u => u.name === 'Max'); // ^? { name: string; age: number; } | undefined if (loggedInUser) { console.log(loggedInUser.age); }  Al manejar explícitamente la posibilidad de   y   , podemos evitar errores de tiempo de ejecución y asegurarnos de que nuestro código sea más robusto y libre de errores. null undefiined  Tipos de funciones estrictas   { "compilerOptions": { "strictFunctionTypes": true } }  Habilitar   hace que el compilador de TypeScript sea más inteligente. Antes de la versión 2.6, TypeScript no verificaba la   de los argumentos de la función. Esto dará lugar a errores de tiempo de ejecución si se llama a la función con un argumento del tipo incorrecto. strictFunctionTypes contravarianza  Por ejemplo, incluso si un tipo de función es capaz de manejar cadenas y números, podemos asignar una función a ese tipo que solo puede manejar cadenas. Todavía podemos pasar un número a esa función, pero recibiremos un error de tiempo de ejecución.   function greet(x: string) { console.log("Hello, " + x.toLowerCase()); } type StringOrNumberFn = (y: string | number) => void; // Incorrect Assignment const func: StringOrNumberFn = greet; // TypeError: x.toLowerCase is not a function func(10);  Afortunadamente, habilitar la opción   corrige este comportamiento y el compilador puede detectar estos errores en tiempo de compilación, mostrándonos un mensaje detallado de la incompatibilidad de tipos en las funciones. strictFunctionTypes   const func: StringOrNumberFn = greet; // ^ Type '(x: string) => void' is not assignable to type 'StringOrNumberFn'. // Types of parameters 'x' and 'y' are incompatible. // Type 'string | number' is not assignable to type 'string'. // Type 'number' is not assignable to type 'string'.  Inicialización de propiedad de clase   { "compilerOptions": { "strictPropertyInitialization": true } }  Por último, pero no menos importante, la opción   permite verificar la inicialización de propiedad de clase obligatoria para tipos que no incluyen   como valor. strictPropertyInitialization undefined  Por ejemplo, en el siguiente código, el desarrollador olvidó inicializar la propiedad   . De forma predeterminada, TypeScript no detectaría este error y podría producirse un problema en tiempo de ejecución. email   class UserAccount { name: string; email: string; constructor(name: string) { this.name = name; // Forgot to assign a value to this.email } }  Sin embargo, cuando la opción   está habilitada, TypeScript resaltará este problema para nosotros. strictPropertyInitialization   email: string; // ^ Error: Property 'email' has no initializer and // is not definitely assigned in the constructor.  Firmas de índice seguras   { "compilerOptions": { "noUncheckedIndexedAccess": true } }  La opción   no forma parte del modo   , pero es otra opción que puede ayudar a mejorar la calidad del código en su proyecto. Permite que la comprobación de las expresiones de acceso al índice tenga un tipo de retorno   o   , lo que puede evitar errores de tiempo de ejecución. noUncheckedIndexedAccess strict null undefined  Considere el siguiente ejemplo, donde tenemos un objeto para almacenar valores en caché. Luego obtenemos el valor de una de las claves. Por supuesto, no tenemos ninguna garantía de que el valor de la clave deseada realmente exista en el caché.  De forma predeterminada, TypeScript asumiría que el valor existe y tiene el tipo   . Esto puede conducir a un error de tiempo de ejecución. string   const cache: Record<string, string> = {}; const value = cache['key']; // ^? string console.log(value.toUpperCase()); // ^ TypeError: Cannot read properties of undefined  Habilitar la opción   en TypeScript requiere verificar las expresiones de acceso de índice para un tipo de retorno   , lo que puede ayudarnos a evitar errores de tiempo de ejecución. Esto también se aplica al acceso a elementos en una matriz. noUncheckedIndexedAccess undefined   const cache: Record<string, string> = {}; const value = cache['key']; // ^? string | undefined if (value) { console.log(value.toUpperCase()); }  Configuración recomendada  En función de las opciones discutidas, se recomienda enfáticamente habilitar las opciones de acceso   y   en el archivo   de su proyecto para una seguridad de tipos óptima. strict noUncheckedIndexedAccess tsconfig.json   { "compilerOptions": { "strict": true, "noUncheckedIndexedAccess": true, } }  Si ya ha habilitado la opción   , puede considerar eliminar las siguientes opciones para evitar duplicar la opción   : strict strict: true   noImplicitAny   useUnknownInCatchVariables   strictBindCallApply   noImplicitThis   strictFunctionTypes   strictNullChecks   strictPropertyInitialization  También se recomienda eliminar las siguientes opciones que pueden debilitar el sistema de tipos o causar errores de tiempo de ejecución:   keyofStringsOnly   noStrictGenericChecks   suppressImplicitAnyIndexErrors   suppressExcessPropertyErrors  Al considerar y configurar cuidadosamente estas opciones, puede lograr una seguridad de tipo óptima y una mejor experiencia de desarrollador en sus proyectos de TypeScript.  Conclusión  TypeScript ha recorrido un largo camino en su evolución, mejorando constantemente su compilador y sistema de tipos. Sin embargo, para mantener la compatibilidad con versiones anteriores, la configuración de TypeScript se ha vuelto más compleja, con muchas opciones que pueden afectar significativamente la calidad de la verificación de tipos.  Al considerar y configurar cuidadosamente estas opciones, puede lograr una seguridad de tipo óptima y una mejor experiencia de desarrollador en sus proyectos de TypeScript. Es importante saber qué opciones habilitar y eliminar de la configuración de un proyecto.  Comprender las consecuencias de deshabilitar ciertas opciones le permitirá tomar decisiones informadas para cada una.  Es importante tener en cuenta que la tipificación estricta puede tener consecuencias. Para lidiar de manera efectiva con la naturaleza dinámica de JavaScript, deberá tener una buena comprensión de TypeScript más allá de simplemente especificar "número" o "cadena" después de una variable.  Necesitará estar familiarizado con construcciones más complejas y el primer ecosistema de bibliotecas y herramientas de TypeScript para resolver de manera más efectiva los problemas relacionados con el tipo que surgirán.  Como resultado, escribir código puede requerir un poco más de esfuerzo, pero según mi experiencia, este esfuerzo vale la pena para proyectos a largo plazo.  Espero que hayas aprendido algo nuevo de este artículo. Esta es la primera parte de una serie. En el próximo artículo, discutiremos cómo lograr una mejor seguridad de tipo y calidad de código mejorando los tipos en la biblioteca estándar de TypeScript. ¡Estén atentos, y gracias por leer!  Enlaces útiles   Referencia de TSConfig   Cualquier tipo   nulo e indefinido

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

This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.

Liberar el poder de TypeScript: consideraciones clave en tsconfig

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

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

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

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

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

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

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

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps