¿Cómo actualizar la solución de SPFX?

Con la llegada del SharePoint Framework (SPFX) aparece una aspecto con el que inicialmente no contábamos, o más bien, no lo considerábamos importante. Se trata de la actualización de nuestra solución a una nueva versión.

Partimos de la base de que el desarrollador de SharePoint estaba acostumbrado a crear el WebPart y una vez el desarrollo ha finalizado, no tiene que preocuparse por nada. Esta forma de trabajar podemos migrarla a la hora de trabajar con el SPFX: creamos un proyecto utilizando Yeoman y una vez creado, no tenemos que modificar nada.

Pero por regla general, no pensamos que los tiempos han cambiado y ahora mismo no tenemos nuestro servidor en nuestras infraestructuras. Lo que tenemos es un SharePoint Online (en algún datacenter de Microsoft) sin importarnos donde esté alojado. Además, nuestros desarrollos son principalmente del FrontEnd, con todo lo maravilloso que esto tiene. Es decir  las herramientas de FrontEnd que se utilizan en el SPFX, son Yeoman, Gulp, Typescript, React, etc… todas ellas tienen una evolución que hace que puedan temblar los cimientos de nuestros desarrollos. Desde que se ha encontrado un fallo grave y que urge modificarlo o incluso alguno un poco más drástico como que haya dejado de funcionar algún elemento del propio FrameWork. Y claro, cuando esto ocurre nuestra solución hay que actualizarla sí o sí.

Cómo actualizamos la solución

En primer lugar tenemos que ver si tenemos el último template de Yeoman, para ello lanzamos el siguiente comando:

npm outdated --global

Si dentro de los paquetes que tenemos instalados está sin actualizar el generador de SharePoint,  lanzamos la siguiente instrucción:

npm install @microsoft/generator-sharepoint --global

Una vez dentro de nuestra solución, lo que debemos de hacer es ir al fichero package.json y actualizar las referencias del paquete a la nueva versión. En este caso tendríamos que poner todos los paquetes en la versión 1.4.1 que es la actual. Quedaría de la siguiente forma:

Una vez actualizado estos paquetes tendríamos que ejecutar el siguiente comando para que se actualicen los paquetes pertinentes:

npm install

Para finalizar, tendriamos que volver a lanzar un Bundle de nuestra solución y …..

¿Qué ocurre una vez compilamos la solución?

Esta es la gran pregunta que nos hacemos los «developers» cuando lanzamos estos comandos. Es posible que en nuestra solución funcione todo a la perfección o es posible que nos de errores (obvio). La cuestión es que en cada  release del SPFX, se van incorporando una serie de cambios que hemos debido leer previamente a la migración de nuestra solución. Por ejemplo, en la versión que lanzaron el otro día sus principales cambios fueron:

– Modificación en los Typings de React
– Deprecaron el GraphClient
– Solventaron una issueç
– Soporte para NodeJS

Viendo todo lo que le puede pasar a nuestra solución, es posible que si hacemos uso del GraphClient tengamos que rehacer estos cambios y adaptarlos a una forma más estable. Otro de los posibles errores que se puedan tener, es que alguna definición de ReactJS se haya modificado y por lo tanto, dé un error de tipado en nuestro código.

¿Cuándo debemos migrar nuestra versión de SPFX?

Por regla general, es conveniente siempre tener la última versión aunque la decisión de cuándo migrar y cuándo no, depende de varios factores:

1.- La solución está en desarrollo. En este caso no hay duda hay que actualizarlo sí  o sí.
2.- La solución está ya en producción. En este caso, depende de que tenga la mejora. Si es un bug crítico  que afecta a la estabilicación de dicho desarrollo, habría que migrarlo y planificar su posterior despliegue y actualización. Si los cambios son menores y no afectan al desarrollo, dejaría de migrarlo para planificarlo en la próxima release.

¿Ésto es todo lo que deberíamos saber?

Como he comentado al inicio del artículo, lamentablemente ésto no es todo :). Si nuestro desarrollo hace uso de alguna librería de terceros, se actualiza sobreb ésta y tiene algún upgrade que sea crítico, también debemos actualizarlo. Por ejemplo:

Estamos haciendo uso del sdk de applicattion Insight. Se ha procedido a una modificación de la API Rest, y si no actualizamos, nos quedamos sin información de diagnostico…En este caso, no nos queda otra opción que proceder a actualizar.

Resumen

En este artículo hemos visto todo lo que significa el nuevo modelo de desarrollo de SPFX.

No solo nos tenemos que centrar en el desarrollo (que es lo que más nos gusta), sino que tenemos que tener en cuenta aspectos como el versionado del template, los últimos cambios que se producen, qué implicaciones conlleva la actualización, etc…
Todo esto  no es ninguna  sorpresa para la gente dedicada al mundo Front, pero  los Office Developers tienen que ir acostumbrándose a esta nueva forma de desarrollo y cuidar más todo el ciclo de vida.