UI5 Tools 3: Novedades y futuro de la extensión

Ya hace un año que lancé la versión 2.0.0 de UI5 Tools, mi extensión de UI5 para VSCode. La característica principal, por la que decidí dar el salto de la versión 1 a la 2, era la incorporación de soporte para aplicaciones hechas con typescript. Hasta hace poco, typescript estaba en fase experimental y sin soporte “oficial” (en relación con UI5). Pues bien, hace apenas unos días que SAP ha anunciado en la UI5con que el soporte pasa a ser oficial. Así pues, he adaptado la extensión para que funcione de la misma forma que con UI5 Tooling + ui5-task-transpile.

¿Pero no tenía ya soporte para Typescript?

Ciertamente, pero el panorama ha cambiado. Anteriormente, al no ofrecer SAP un soporte oficial, utilizaron una estructura de carpetas en la que seguía existiendo el código transpilado a javascript. El proceso lo describí en este otro artículo. Así pues, debías tener dos carpetas para poder desarrollar aplicaciones: src --> webapp en el caso de aplicaciones y src --> src-gen en el caso de librerías. En las primeras tendríamos el código escrito por nosotros en typescript, mientras que la segunda contendría el código transpilado automáticamente a javascript. Esta última carpeta es la que se utilizaba en el servidor local para probar el código en el navegador.

Ya hace un tiempo que las herramientas oficiales no estaban utilizando este sistema, pero al no haber ningún anuncio oficial de soporte a typescript preferí no cambiar nada. Eso y también que en el principal proyecto en el que estoy implicado me habría supuesto un trabajo de adaptación de aplicaciones que prefería ahorrarme 😂.

Pues bien, el anuncio ha llegado. A partir de la versión 3, para utilizar typescript, la estructura de carpetas pasa a ser la estándar: webapp para aplicaciones y src para librerías. El código typescript se transpila a javascript al vuelo cuando el servidor local lo vaya a enviar al navegador. Ya no se guardará en disco una versión en javascript. Naturalmente, seguiremos teniendo sourcemaps, con lo que podrás debugar en el navegador el código fuente original escrito en typescript sin problemas.

Adiós Internet Explorer

Otra de las novedades de la versión 3 es la ausencia de soporte a transformaciones de javascript compatibles con Internet Explorer. Es algo que quería hacer desde el día 0 en el que Microsoft oficializó el end-of-support. Evidentemente, por motivos laborales no podía hacerlo, ya que comprometía ciertos proyectos en los que estoy involucrado. Especialmente por problemas relacionados con el SAP GUI, HTML Viewer con WebView2 abriendo una aplicación UI5 en https que lanza SAPEVENT. En otro artículo ya hablaré sobre los SAPEVENT, que dan para mucho…

Aunque el problema persiste de alguna manera, en HTTP funciona. O por lo menos lo hacía hasta la versión inferior a SAP GUI Windows 7.70rev12. Actualmente, no conozco a nadie cercano que necesite soporte a IE10.

Si necesitas seguir soportando Internet Explorer… muchos ánimos 🫶🏻. Puedes seguir utilizando la extensión en 2.2.2 o utilizar ui5 tooling.

Origen y evolución de la extensión

La extensión nació como una evolución a una primera herramienta local de desarrollo que hice con grunt. Lo hice para poder salir de Eclipse y pasar a VSCode. Ésta a su vez, evolucionó a un servidor local node. Llegados a este punto, el paso a una extensión de VSCode era bastante obvio. El UI5 Tooling era relativamente nuevo y no permitía lanzar todas las aplicaciones de golpe, cosa que necesitaba y sigo necesitando.

Respecto al futuro de la extensión, no tengo muy claro que hacer. He pensado muchas veces “dejarla morir”. Pero, para mí, sigue siendo mucho más cómodo, en entornos con Gateway, tener un servidor único. Todos los proyectos relacionados alojados en un mismo espacio de trabajo. En cambio, con UI5 Tooling me implica tener un montón de proyectos, cada uno con su espacio de trabajo, con sus dependencias, sin poder levantar todas las aplicaciones a la vez, etc.

Sobre todo porque al estar todas las aplicaciones en el mismo Gateway, las dependencias vienen a ser las mismas y puedo emular el comportamiento del gateway en local, simplificándolo todo. También puede ser que me haya acostumbrado a trabajar así y sea reticente al cambio 😅. Fuera bromas, el UI5 Tooling ha mejorado muchísimo, pero sigue sin dar respuesta a una necesidad de mi día a día.

Pero por otro lado, hay muchas cosas que ahora se pueden hacer de forma oficial: consumir dependencias de node_modules, el nuevo build con custom-bundle en el que no hará falta cargar todo UI5, UI5 Web Components… Son cosas que no tengo intención de añadir a la extensión, pero que me gustaría poder incorporar a los proyectos en los que trabajo 🤞.

En definitiva, de cara a 2028 con la muerte de UI5 1.71 y el resto de LTS actuales, es posible que la extensión deje de tener sentido. Quizá para entonces todos estamos en BTP 🚀, no quede ningún Gateway… 👻 y pueda deprecar la extensión 👋.