[idea] Make customizing tasks without editing gulpfile easier

[RoxKilly]

This is an idea I think would help the community if implemented. Pls let me know what you think

the challenge
We need to customize tasks without editing gulpfile.ts since that will be replaced (and our edits lost) when the repository is updated

the current solution
We can overwrite any task in tools/tasks/seed/ by writing our own, giving it the same name as the built-in task, saving it in tools/tasks/project/. So far so good

what's still missing
Sometimes we need to change the tasks defined in gulpfile.ts itself, and all we need to do is one small change that doesn't require a full rewrite. For instance here is my use case: once the project is built and files are placed in destination folder, I need to move them all into a remote folder from which my webserver actually serves the files. To accomplish this right now, I have two options:

1. Copy every build task in gulpfile.ts and paste it in tools/tasks/project/ as one of my own that does the exact same thing as the built-in, but has one additional step.
2. Edit gulpfile.ts to insert my step into every build task. For instance:

// Build dev.
gulp.task('build.dev', (done: any) =>
  runSequence(
              ...,
              'push', // I inserted my task to move built files to a remote folder
              done));
// --------------
// Build prod.
gulp.task('build.prod', (done: any) =>
  runSequence(
              ...,
              'push', // I inserted my task to move built files to a remote folder
              done));

Neither of these options is very good.

my proposal
For the built-in build and serve tasks in gulpfile.ts, add a step at the beginning and a step at the end, that will serve as hooks for the developer to customize the task. For example:

// Build dev.
gulp.task('build.dev', (done: any) =>
  runSequence(
              'pre.build.dev'
              ...,
              'post.build.dev'
              done));

The files tools/tasks/seed/pre.build.dev and tools/tasks/seed/post.build.dev would do nothing. However this gives the developer the opportunity to create files by the same name in tools/tasks/project that would do something useful.

For me, I could perform my push tasks within tools/tasks/project/post.build.dev, without the need to edit gulpfile.ts.

PS: similar hooks could be inserted into other build and serve tasks. What do you think?

[mgechev]

Sounds good to me.

In the past I've been thinking to take this even further. Now we define terminal (leaf) tasks in tools/tasks, there are also non-terminal (composed) tasks which are defined in gulpfile.ts.

We can introduce files tasks_seed_config.json (we should come up with a better name) and tasks_project_config.json where we can have the following task definition:

{
  "build.dev": [
    "clean.dev",
    "tslint",
    "build.assets.dev",
    "build.html_css",
    "build.js.dev",
    "build.index.dev"
  ]
}

Once we parse the JSONs we'll get two JavaScript objects - composed tasks for the project and the seed. We can perform deep merge in order to allow the project to override the seed's composed tasks.

What do you think?

[RoxKilly]

@mgechev I like your idea much better. It would take more work to implement than just adding noop placeholder tasks as I suggested, but it would provide a ton more flexibility

[gforceg]

Would it be beneficial to add something like this to seed.config.ts?

  // The directory of the tasks created by the project.

  PROJECT_TASKS_DIR = join(process.cwd(), this.TOOLS_DIR, 'tasks', 'project');

[gforceg]

I created a project task to generate TODO.md using gulp-todo. I wanted to auto-generate TODO.md based on comments for each TS file in Config.APP_SRC as well as the tasks in /tools/tasks/project.

I added this.PROJECT_TASKS_DIR, to project.config.ts but I thought maybe it should already exist since it's part of the architecture of seed.

I don't think it conflicts w/ the proposed tasks_seed/project_config.json files. Do you think there are other use cases as well?

[mgechev]

@gforceg, no it should be fine to add such property.

[mgechev]

@RoxKilly you can take a look at the implementation here #1675.