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

En este artículo, vamos a ver como podemos incluir nuestras tareas personalizadas dentro del proceso de Build. Para  entender el contenido del mismo, es necesario conocer los ficheros que hay dentro de una solución del SPFX (SharePoint Framework), para lo cual recomiendo leer este artículo 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 podemos incluir dentro de nuestro proceso de compilación, es la verificación de nuestro HTML con herramientas como Handlebars

¿Cómo 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[];
}

• Execute ->  Aquí pondremos la lógica que va a tener nuestra tarea personalizada.
•  «name» -> Pondremos 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 será registrar nuestra tarea dentro del Pipeline de la Build. Para ello, dentro del fichero gulpfile.js deberemos 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 nos 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 si lo preferís, podéis utilizar otras utilidades como 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 final de la misma (esto lo hacen las otras tareas y es recomendable, sobre todo  de cara a seguir una estandarización de las mismas).

Una vez tenemos la tarea, el siguiente paso es añadirla dentro de nuestro pipeline. Este proceso ha sufrido algunos cambios desde la primera versión. Ahora mismo y tal como pone en esta 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. No obstante, considero que por el mantenimiento y la legibilidad del código, es 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, que debe de dominar todas las herramientas de Front-End para poder sacarle el máximo 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.