Speed-up the development build

[mgechev]

Problem

Recently, while using the seed, I had to create a task which execution takes 5s. It is for svg sprite creation and compression but it was triggered on any file change. This is a lot for dev build since it blocks everything else, so the livereload cannot refresh the browser until the execution of the slowest task completes. I thought what we can do and with the current stateless task management (which is great but a bit limiting) there was no right way to approach.

Proposal

I was thinking that we can have a global state, which is mutated by utils/seed/watch.ts. So for instance:

export function watch(taskname: string) {
  return function () {
    let paths:string[]=[
      join(Config.APP_SRC,'**')
    ].concat(Config.TEMP_FILES.map((p) => { return '!'+p; }));

    plugins.watch(paths, (e: any) => {
      changedFiles.add(e.path);
      runSequence(taskname, () => {
        changedFiles.clean();
        notifyLiveReload(e);
      });
    });
  };
}

Later in the individual tasks, based on the file type we can check if any of the changed files requires their activation and can be skipped otherwise. For instance:

// build.js.dev
export = (done: any, filesChanged: string[]) => {
  if (hasTypeScriptFile(filesChanged)) {
    return gulp.src(...)
           .pipe(ts())
           .pipe(gulp.dest(...));
  } else {
    done();
  }
};

We can extend this even further by exporting not only a single function but a task object which processes only tasks of given type and/or has any other activation preconditions:

type FileType = RegExp;

interface ITask {
  precondition(files: string[]);
  processFiles?: FileType[];
  run(done: any): GulpStream | any;
}

const task: ITask = {
  precondition(files: string[]) {
    // decide if it should be activated
  },
  processFiles: [/\.ts$/],
  run(done) {
    // ...
  }
};

By default given task will be executed in all cases.

In order to keep the code DRYier, it'll be best to move the filtering logic in the task runner in tasks_tools.ts.

Basically it'll be a type of a chain of responsibility with inversion of control, because the tasks are not the ones which decide if the rest of the tasks in the chain should be executed.

[Bigous]

In this case, the clean and livereload can be notified only if something that matters changes. Good.

[mgechev]

PR coming today.