Task aliases

[dallonf]

Goals

Sometimes you need a bit less coupling between the task graph and package.json scripts. It'd be nice to be able to assign a name to a task that doesn't exactly match its counterpart in package.json.

Proposed example in turbo.json:

"tasks": {
  "build": {
    "alias": "build:turbo"
  }
}

Which would correspond to a build:turbo task in package.json:

"scripts": {
  "build": "This one is what happens when you run `npm build`",
  "build:turbo": "But this is what happens when you run `turbo build`"
}

Non-goals

1. Defining tasks outside of package.json scripts (ex. as shell scripts)

Background

Had two situations recently where this would have been helpful.

In the first, a team had defined their build task as "build": "npm codegen && next build", not realizing the redundancy (since codegen is a Turborepo prerequisite of build at the global level). When I asked them why and clarified Turborepo's behavior, they expressed reluctance to remove the redundancy and use Turborepo to run actions (i.e. they'd rather run npm build than turbo build, especially in the scope of a single project.)

This is more reasonable than it sounds, since not all of our npm scripts make sense to be managed by Turborepo, and I empathize with the cognitive overhead of needing to remember when to run turbo and when to run npm.

I managed to win that debate, but with task aliases, we could have compromised by aliasing Turborepo's build task to something like build:app in npm, allowing the vanilla build script to be npm codegen && npm build:app.

In the second, I was building a package that needed a task for code generation to be run manually, not as part of a build process. Now we already have a codegen task defined for many other packages, but that is included in the dependency graph because it's lower risk to run.

If I were to call this new task codegen, it would be run by Turborepo at potentially surprising times. If I could alias this project's codegen task though to something else (maybe codegen:auto), I could keep the conventional name without running into surprising behavior. (It would even be cool if I could remove the codegen task from this project, but that seems like a separate feature request).

As a workaround, I called the task codegen:manual.

As I write these use cases, I realize they seem a bit contrived and my "workarounds" might actually be preferable solutions over aliasing tasks. But the feature request still seems useful to me, so I figured I'd share it.

Proposal

Don't know how it'd be implemented, but it seems straightforward to me. I'd be willing to contribute if I knew it was likely to be merged.