[Vinnl]

Here's an example: https://gitlab.com/vincenttunru/penny/-/blob/main/scripts/bu...

That used to be a shell script. But this I can way more easily read (even after not touching it for a long time), I get autocompletion, and I can use the APIs I'm already familiar with. It's a pretty neat QoL improvement for me specifically.

[latchkey]

Wouldn't the `await fs.move` run sync? Why not just return the Promise from fs.move() so that Promise.all() can run the multiple moves async?

  await Promise.all(
    unneededPages.map(async (page) => {
      await fs.move(page, `scripts/.cache/${page}`, { overwrite: true });
    })
  );

Similar to what you do on line 26.

[Vinnl]

Do you mean the `await fs.move` on line 13? Because yes, I do need that to complete before I can run the next command, the build, on line 40.

I could have appended it to the Promises that I'm creating on line 9 to run it in parallel with those moves, but this is not performance-critical code, and moving the two conceptually-unrelated concepts into the same expression wouldn't aid legibility, in my opinion. And since I'm the only one who needs to read the code, that opinion wins by default :)

[latchkey]

Above: You have `await Promise.all()`. Remove the `await` in front of `fs.move()`.

You don't need the second `await` for blocking purposes.

Sure, it is your code to do as you like, but if you're going to post it as an example, you might want to correct it first so that others don't make the same mistakes.

[Vinnl]

Ah! You mean that

    await Promise.all(
      unneededPages.map(async (page) => {
        await fs.move(page, `scripts/.cache/${page}`, { overwrite: true });
      })
    );

could also have been written as

    await Promise.all(
      unneededPages.map((page) => {
        fs.move(page, `scripts/.cache/${page}`, { overwrite: true });
      })
    );

That is absolutely correct! I wasn't intending it as an example of how to write flawless JS code though, just as an example of the type of script that ZX is useful for - but if I remember next time I open my dev env, I'll update it :)

Edit: though maybe I'm misunderstanding given that you said it would make them run sync, because as far as I know, the functions would still run in parallel? Essentially, I believe it would roughly be the equivalent of this:

    await Promise.all(
      unneededPages.map((page) => {
        fs.move(page, `scripts/.cache/${page}`, { overwrite: true });
      }).then(result => result)
    );

[elygre]

What’s with all the await-stuff? Couldn’t it be written just straight forward?

[Vinnl]

That allows other code to run while e.g. files are being moved. It indeed can be somewhat painful ([1] is the classic criticism) and in shell scripts is not as beneficial. I think there are even sync alternatives (i.e. equivalent functions that don't need `await`) for most of them, but again: these are the APIs I'm already familiar with, which is the entire point - and thus the await-stuff comes naturally for me, because I intuitively know those APIs are async.

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

[imglorp]

Yes and a shell script would do it with one &, while this goop is a mountain of async, nesting, futures management, and boilerplate. No thanks.

[Vinnl]

Sure, but again: I know and recognise this syntax and the APIs. What's boilerplate to me, I hardly see, whereas compact Bash operators are noise to my eyes.

[Vinnl]

(Though to be honest, I'm also somewhat sceptical that a single & in Bash would be sufficient to move a bunch of files in a particular order, and restore them properly if the process gets terminated somewhere halfway along the process. But what I'm sure about is that I wouldn't have been able to write that in a reasonable amount of time!)