Reemplazando Scripts de Shell con TypeScript Multiplataforma

Hola a todos. Soy David Sherrit, un desarrollador en Deno, y hoy hablaré sobre por qué deberías reemplazar tus scripts de shell con TypeScript multiplataforma. Esto no es solo una charla para desarrolladores de JavaScript, sino para desarrolladores de cualquier lenguaje y experiencia.

Personalmente, TypeScript no es mi lenguaje principal, pero lo uso en casi todos mis proyectos, y esta charla explicará cómo y por qué también deberías considerar hacerlo.

Entonces, ¿por qué usamos scripts de shell? A menudo los usamos porque funcionan de inmediato en el sistema en el que estamos, por lo que es conveniente. Son fáciles de ejecutar. Tienen una sintaxis concisa y se ejecutan de manera similar a lo que escribimos en la línea de comandos. Entonces, si tienes un comando que ejecutas con frecuencia en tu terminal, a menudo puedes copiarlo y pegarlo en tu script de shell. Sin embargo, hay algunas desventajas. La primera gran desventaja es que dependen del sistema. Los scripts de shell no se pueden ejecutar en todas las plataformas. En su mayoría, no se ejecutarán de inmediato en Windows. A veces, esto también ocurre en sistemas basados en Unix, dependiendo de cómo esté escrito el script de shell. Además, los comandos básicos de Unix no funcionan de inmediato en Windows. Y decirles a los desarrolladores de Windows que usen WSL no es una gran solución. Eso puede requerir que configuren un nuevo entorno de desarrollo dentro de WSL solo para ejecutar el script. Los scripts de shell son excelentes si estás ejecutando unos pocos comandos, pero es difícil aumentar la funcionalidad sin aumentar drásticamente la complejidad.

Otro punto específico para los desarrolladores de JavaScript es que los scripts de shell presentan código que debemos mantener en otro lenguaje. Tampoco podemos usar nuestras bibliotecas favoritas de JavaScript. Por último, no hay verificación de tipos. No obtenemos autocompletado de código para ayudarnos a desarrollar y todas las demás herramientas agradables que TypeScript proporciona.

Ahora, ¿por qué deberías usar TypeScript en lugar de scripts de shell? En primer lugar, es familiar, y TypeScript y JavaScript son lenguajes populares con una gran comunidad. Muchos desarrolladores al menos han tocado JavaScript o al menos pueden entender su sintaxis. En segundo lugar, está la verificación de tipos y las herramientas. Un gran beneficio de TypeScript es que sus herramientas son excelentes, incluso si solo estamos usando JavaScript. Obtenemos funciones como autocompletado de código, ir a la definición y errores de verificación de tipos en el editor.

Esta charla no solo trata sobre por qué deberías reemplazar los scripts de shell con TypeScript, sino también por qué deberías usar Deno mientras lo haces. En primer lugar, es mucho más fácil escribir scripts multiplataforma en Deno que scripts de shell, porque la mayoría de las API funcionan en varias plataformas. Obviamente, hay algunas API específicas de la plataforma, si las necesitas, pero generalmente no tenemos que recurrir a ellas.

En segundo lugar, tenemos los scripts de un solo archivo. Obviamente, estoy sesgado, pero creo que Deno es la mejor plataforma para escribir scripts de un solo archivo. Por ejemplo, en Node, usar TypeScript requiere una configuración adicional. Necesitas tener un archivo package.json para definir las dependencias. Esto también requiere que cualquier persona que ejecute tus scripts recuerde ejecutar npm install primero y también después de cualquier cambio en las dependencias. Ese proceso crea una carpeta de módulos de Node en el árbol de directorios. Por lo tanto, ya tienes dos entradas adicionales en el sistema de archivos, por lo que no es un script de un solo archivo.

Por otro lado, en Deno, TypeScript es compatible de forma nativa, por lo que puedes ejecutar código TypeScript directamente. Es opcional usar un archivo de configuración para definir tus dependencias, y también es opcional tener una carpeta de módulos de Node para las dependencias de npm. Es importante tener en cuenta que aún puedes usar ese modelo si lo deseas, pero es opcional. En tercer lugar, las dependencias se instalan automáticamente según el código, por lo que no es necesario ejecutar un comando de configuración separado como npm install.

Finalmente, Deno está sandboxed por defecto. Node recientemente obtuvo un sistema de permisos experimental, pero es opcional en lugar de ser obligatorio. Otra gran ventaja de Deno para scripting de un solo archivo es que es posible definir las dependencias en el propio archivo de script. Por ejemplo, puedes importar paquetes de npm o usar importaciones https para alojar fácilmente scripts en un servidor web y hacer referencia a ellos directamente. Una parte negativa de esto es que es verboso lanzar subprocesos utilizando una API de proceso de bajo nivel disponible tanto en Node como en Deno. Pero eso no es un gran problema, porque podemos importar una dependencia que ayuda a que sea más similar a los scripts de shell. Hay una biblioteca que escribí llamada dax. Dax es una shell multiplataforma escrita en JavaScript que tiene comandos comunes de Unix integrados. También tiene otras API útiles para ayudar con el scripting.

Aquí hay algunos ejemplos de ejecución de comandos. La sintaxis de la shell que admite es una sintaxis común que se encuentra en los scripts de shell. Para casos más complejos, como bucles, probablemente quieras usar JavaScript en su lugar. Nuevamente, para enfatizar, todo el código mostrado aquí funciona en Windows. Lanzar comandos es un poco más verboso que los scripts de shell para casos simples, pero en mi opinión, las ventajas de poder escribir estos scripts principalmente en JavaScript superan la ligera verbosidad adicional al lanzar comandos. Además, se podría argumentar que esto es menos verboso en casos complejos. Por ejemplo, como se muestra en la última línea de este código, acceder a las propiedades de la salida JSON de un comando es bastante fácil.

Finalmente, DAX tiene API de registro, una API de ruta. Por ejemplo, aquí creamos un objeto de referencia de ruta para el directorio fuente, verificamos si es un directorio y luego llamamos a mkdir para crear el directorio. Luego obtenemos una referencia a un archivo de texto dentro de ese directorio, escribimos algo de texto en él o incluso podríamos leer desde ese archivo de texto. O podríamos escribir algún objeto como JSON en un archivo o leerlo deserializándolo en un valor JSON. También hay API para hacer preguntas, hacer selecciones y mostrar progreso. Finalmente, hay una API de solicitud incorporada que es similar a la API fetch, pero menos propensa a errores y con algunas funciones adicionales.

De todos modos, hay mucho más en esto, y recomendaría consultar la documentación para obtener más detalles. Gracias por escuchar mi charla.