Tasks: Is property `.name` really needed?

[rauschma]

I’m curious: Does the object passed to task() really need a property .name? If Hereby does a namespace import then it already has all the names(?) It could even add the property automatically to whatever data structure it uses internally.

import { execa } from "execa";
import { task } from "hereby";

export const build = task({
    name: "build",
    run: async () => {
        await execa("tsc", ["-b", "./src"]);
    },
});

[jakebailey]

It's a lot easier to make something optional than to make it required; when I made this package, its intended use was solely as a replacement to TypeScript's use of gulp, where our build tasks included tasks with chracters that were illegal in JS identifiers. It seemed fairly safe to require the names (as gulp did). At the time, there was no way to do export { foo as "build:compiler" } or similar either. So, I made the option required.

I do have a local branch (years old at this point 😅) which does what you suggest, as the list of exports would neccesarily have unique names. The gotcha is that the mappings of tasks to their names would then be "external" to the tasks themseleves (since I do not want to mutate the tasks themselves).

It's hard to know how beneficial it is; the downside is that renaming a task will also change its name, which I've previously had to do in order to lift code from a task out into a function for reuse (e.g., in your case I'd have done exprot const buildTask = ...; async function build() {}).

---

Of course, I'm mostly curious what you're using hereby for; I'm always surprised when someone actually uses it outside TypeScript.

[rauschma]

Got it, thanks!

I’m currently exploring simple task runners (make, npm run, taskfile.dev, just.systems, etc.). I like Hereby’s simplicity (for JavaScript programmers...).

[jakebailey]

I'm open to changing this, of course; it would be simpler if it just auto named them based on the exports. Going to leave this open while I think / gather feedback.

[jakebailey]

I know it's silly, I've just resisted adding anything and everything; this package is <500 lines of actual shipped code, which I am somewhat proud of 😄

That being said, this is not that many lines of code at all.