Arquitectura, buenas prácticas y desarrollo sobre la nueva herramienta de Microsoft SharePoint 2016

SPFX: Añadiendo tareas de Gulp al proceso de compilación

`gulpEn este artículo, vamos a ver como podemos incluir nuestras tareas personalizadas dentro del proceso de Build. Para poder entender el contenido del mismo es necesario conocer los ficheros que hay dentro de una solución del SPFX (SharePoint Framework) para ello recomiendo leer este articulo previo.

El proceso de compilación que trae por defecto el SharePoint Framework es el siguiente:

  • Arranca el servidor
  • Copia ficheros necesarios en el mismo
  • Compila el SASS
  • Verifica la sintaxis del TypeScript con TSLint
  • Compila la solución
  • Copia los ficheros de recursos
  • Configura WebPack
  • Modifica el fichero de manifiesto
  • Arranca nuestra aplicación

Este proceso de serie es bastante completo, puede cumplir con el día a día de muchos desarrolladores. Sin embargo, dependiendo del tipo de desarrollo que se lleve a cabo, es posible que te haga falta extenderlo. Por ejemplo, si utilizas templates html y no lo quieres incluir dentro del bundle, para que te funcione deberás de copiar este template dentro del servidor.

Otra tarea que es posible que queramos incluirla dentro de nuestro proceso de compilación, es la verificación de nuestro HTML con herramientas como Handlebars

¿Como lo extendemos?

Las tareas de la Build que se utilizan en el SPFX implementan la siguiente interfaz:

export interface IExecutable {  
  execute: (config: IBuildConfig)=> Promise<void>;
  name?: string;
  isEnabled?: () => boolean
  getNukeMatch?: (config: IBuildConfig, taskConfig?: {}) => string[];
}

Donde en:

  • Execute -&amp;gt;  pondremos lógica que va a tener nuestra tarea personalizada.
  •  “name” -&amp;gt; el nombre de la tarea.
  • getNukeMatch, devuelve un vector de ficheros que se deben de limpiar cuando se utiliza la tarea gulp nuke.

Cuando tengamos definida nuestra tarea, el siguiente paso es registrar nuestra tarea dentro del Pipeline de la Build. Para ello, dentro del fichero gulpfile.js deberemos de añadir nuestra tarea utilizando la llamada build.rig.addBuildTastk().

Un ejemplo práctico

Vamos a implementar una tarea que copie todo los templates de html que utilizamos en nuestros WebPart dentro del servidor NodeJS para que cuando intentemos acceder a ellos no de error.

En primer lugar, nos creamos un fichero javascript llamado copyTemplates.js. En este fichero añadiremos el siguiente código:

'use strict';  
var error = require('@microsoft/gulp-core-build').error,  
  log = require('@microsoft/gulp-core-build').log;

var CopyTemplates = {  
  execute: (config) => {
    return new Promise((resolve, reject) => {
        var time= new Date();
        var res = time.getDate();
      log(`Starting subtask 'copyTemplates'...`);
      config.gulp.src('./src/webparts/**/*.html')
        .pipe(config.gulp.dest('./temp/'));      
      log(`Finished subtask 'copyTemplates'... `);
      resolve();
    });
  },
  name: 'copytemplates'
};
exports.default = CopyTemplates;   

El código anterior es bastante simple, lo único que hay que tener en cuenta, es utilizar el error y el log que te da el propio SPFX; aunque en el caso que se quiera, se puede utilizar otras utilidades como puede ser gulp-logger.
Otra de las cosas que hay que tener en cuenta a la hora de implementar la tarea, es incluir un Log de inicio y de final de la misma (esto lo hace las otras tareas y es conveniente de cara a seguir una estandarización de las mismas).

Una vez tenemos la tarea, el siguiente paso es añadir la tarea dentro de nuestro pipeline. Este proceso ha sufrido algunos cambios desde la primera versión. Ahora mismo y tal como pone en la siguiente Issue se hace de la siguiente forma.

Para ello, editamos el fichero gulpfile de la siguiente forma:

'use strict';
const gulp = require('gulp');
const build = require('@microsoft/sp-build-web');
const copytemplates = require('./copyTemplate');
build.rig.addBuildTasks(copytemplates); 
build.initialize(gulp);

También es posible añadir las tareas directamente sin la necesidad de cargar ningún fichero previo, pero considero que por el mantenimiento y la legibilidad del código, es mucho mejor opción que escribirlo directamente en el propio fichero de gulpfile, aunque se puede hacer de la siguiente forma:

const gulp = require('gulp');
const build = require('@microsoft/sp-build-web');
const firsttask = build.subTask('firsttask', (gulp, buildConfig, done) => {
  // task code
  return Promise.resolve();
});
const secondtask = build.subTask('secondtask', (gulp, buildConfig, done) => {
  // task code
  return Promise.resolve();
});
build.rig.addBuildTasks(firsttask);
build.rig.addBuildTasks(secondtask);
build.initialize(gulp);

Conclusión

Hemos visto que ahora mismo el desarrollador de SharePoint es un desarrollador Web, debe de dominar todas las herramientas de Front-End para poder sacarle el mayor partido a este nuevo modelo de desarrollo.

Uno de los aspectos más novedosos del SPFX, es la libertad para extenderlo según las necesidades de cada uno, así como la extensión y utilización de las herramientas que el desarrollador escoja.

mm

Sobre Adrián Díaz

Adrián Díaz es Ingeniero Informático por la Universidad Politécnica de Valencia. Es MVP de Microsoft en la categoría Office Development desde 2014, MCPD de SharePoint 2010, Microsoft Active Profesional y Microsoft Comunity Contribuitor 2012. Cofundador del grupo de usuarios de SharePoint de Levante LevaPoint. Lleva desarrollando con tecnologías Microsoft más de 10 años y desde hace 3 años está centrado en el desarrollo sobre SharePoint. Actualmente es Software & Cloud Architect Lead en ENCAMINA.
Esta entrada ha sido publicada en spfx, typescript y etiquetada como , , . Enlace permanente .
ENCAMINA, piensa en colores