Plan for v8

[antonmedv]

Here is a plan of what I'm planning to do for the next v8 release. Feel free to join, by picking one on the objectives.

v8

• Set $.verbose = false by default ∅
  • stderr should be echoed by default.
  • stdout should not be printed by default.
• Refactor $ to support const $$ = $({...}) syntax.
  • AbortController support by $.
  • Split $ into a separate package with minimum dependencies. (probably)
    • Add zx/core.
  • Remove ps-tree dependency.
  • (probably) Deprecate within().
    • Refactor process.cwd() calls
  • Add trim to ProcessOutput::valueOf(): string
  • Add $.sync API.
• Use bash by default on Windows (and fail if not found, with ZX_SHELL env config).
• Use node18 by default (but allow zx to run on node16 too).
  • Remove node-fetch dependency (node18 already has fetch, this allows to drop DOM lib in ts).
• Add some CI tests for deno.
• Bundle deps.

Future

• Better support for multiline commands.
• Better support for dotenv.
• $.log refactoring (probably)
• Remove fs-extra dependency (probably)
• Add exit()
• Add pool()
• Add progressBar()
• Improve retry()
• Improve --install
• Add API for plugins*

Note: Before submitting PR, discuss implementation and API.
Note: * - complex task.

[stevage]

Is this the place to discuss these plans?

If so: personally I am glad that fs-extra is included by default. It includes fs.readJsonSync() which is exactly the kind of convenience that is nice in zx.

It also isn't clear whether the above addresses #636. What I (and I think others) would like is a decoupling of:

• whether the command is printed
• whether stdout is printed
• whether stderr is printed

[antonmedv]

My idea about new verbose mode for $:

• Set $.verbose = false by default
• stderr should be echoed by default.
• stdout should not be printed by default.

I also was planning to drop fs-extra by default.

[stevage]

IMHO the default behaviour should be similar to a Bash script:

• command is not echoed
• stdout is printed
• stderr is printed

If you make stdout not printed by default it will be confusing in a case like:

$`echo Hello world`

which well then of course behave differently from

echo`Hello world`

What's the rationale?

[antonmedv]

JS equivalent of echo is console.log. The problem with outputting $ by default is what we cannot distinguishes how it used:

await $`some-command`

versus

const output = await $`some-command`

So the idea is to not output anything(defaul behavior), allow to override with $.verbose =true.

Or you can simple redirect stdout:

await $`some-command`.pipe(process.stdout)

[stevage]

JS equivalent of echo is console.log.

Personally, I think of ZX as a replacement for Bash, so it's more important that it works, by default, similarly. Most of my scripts have the expectation of being a little bit noisy - running commands, and having the output go to the console, so the user can see what is happening while it is running.

Making it so that doesn't happen is the Bash equivalent of writing > /dev/null at the end of every line, which would, for me, be unusual.

I don't dispute that there are situations where it's preferable not to pass stdout to the command line, but I think the default should be around the other way. And of course, changing the default will change the behaviour of every existing script.

Perhaps you'd consider additional per-command flags in any case, which would also protect scripts against future changes to this default:

await $.noisy`some-command`

const output=$.quiet`some-command`

[antonmedv]

What is different between $.noisy and .pipe(process.stdout)?

[stevage]

I don't know, because I haven't tried the pipe method, and it wouldn't necessarily occur to me either. Thus far in my usage of zx, have not had to use .pipe() or process.stdout.

[lawrenceching]

Suggest to release the v8 document ASAP.

I take hours to find out why the default value changed for $.verbose.
npm install v8 for me by default, and I didn't aware of that. I kept checking the v7 document and feeling confused.

[43081j]

i see v8 is out already so this can't really happen until 9.x i suppose - but it would still be good to reduce the size of zx a bit

we could do that a few ways:

• replace chalk with picocolors (happening widely across the ecosystem already)
• replace fs-extra with a much smaller subset of inlined utils
• replace globby with tinyglobby or fdir

but since we expose these in the public interface, it'd be a breaking change for any of them

[antonmedv]

We do a bundling for zx. So now zx kina small.

[43081j]

You do indeed do bundling. it is 3MB+, it can be smaller

800KB+ of that is the bundle, which we could certainly reduce (the rest is mostly @types/node)

2 of the suggestions above will also improve performance, so this is not only about footprint

[stevage]

It's a backend tool. Bundle size seems pretty irrelevant. It would be pretty annoying to lose functionality or even to make breaking changes in support of that goal. In any case, the bundle size issue doesn't have anything to do with this issue.

[43081j]

bundle install size and performance are always relevant (we're not bundling here)

picocolors is faster than chalk and is much smaller. this one would change the public API slightly in that we wouldn't support RGB colours anymore (only the standard term/ansi colours)

globbing can be achieved with fdir and picomatch, which will be much faster and achieve the same public interface (ability to pass globs).

i agree it would be pretty annoying to lose functionality, or make breaking changes. luckily, we don't have to. the only lost functionality would really be the RGB function in chalk

this stuff does matter even if not for you specifically. its part of a much wider effort to improve perf across the ecosystem, im only here trying to help.