Running tasks in parallel about scripty HOT 12 CLOSED

Scripty is already so close to being able to do this since it's just using async.series here.

The trick of implementing this would be:

1. How should users flag it? A package.json-wide option would be too broad, a CLI arg would be problematic given the expectation they be forwarded in #5 and #6 -- maybe an ENV var? SCRIPTY_PARALLEL npm run test?
2. Testing it well sounds like work.

from scripty.

How should users flag it?

I intentionally left it out of the description 😅

A package.json-wide option would be too broad

Agreed.

a CLI arg would be problematic

Makes sense.

maybe an ENV var

Too broad? I'd expect to only run specific aggregate tasks in parallel. The only idea I had was a naming convention like &test (& inspired by Bash to run all test:*).

from scripty.

Ahh, considering parent/aggregate tasks specifically, that is a good point. Maybe the answer is there.

I don't feel like an ENV var is too broad if it's defined inline (since it won't stick the shell session), but the idea of tweaking the naming convention is really clever. I'm going to play with that

from scripty.

Turns out that using & (as in npm run &test or npm run test&) blows up in mysterious ways.

Is there another character that might imply parallelism? What about npm run test+? That at least works?

from scripty.

I didn't consider that 😣 I'm weary because of lack of precedent for any other symbol I considered. What about something literate like test.parallel?

from scripty.

Eh at that point I'd be more comfortable with the env var. using an actual word means there's a chance someone might accidentally stumble upon it and get real confused.

from scripty.

Also how about a word other than parallel? It's hard for most people to spell

from scripty.

I'd be more comfortable with the env var

Should it also be propagated to subtasks e.g. NODE_ENV=production?

how about a word other than parallel

async?

What about npm run test+

Reviewing valid characters that does look best!

from scripty.

Yes, one reason I like the env var (assuming it's namespaced to scripty to avoid collision like SCRIPTY_GO_FAST=true npm run test) is because downstream scripts you write could alter their behavior when running in parallel to avoid any locking problems / race conditions, etc.

from scripty.

Another reason I like the env var is that users wouldn't need to edit or duplicate an entry in their package.json just to switch between parallel and not (which I often want to do, for instance, when watching, so that I can get more sane stdout across two tabs)

from scripty.

this may be the best option

from scripty.

Yeah, based on the documentation, you'd think a config key would be the best bet, but I'm having a really hard time successfully overriding package config entries. I think the nut of it is the npm config docs are mostly about modifying core npm settings at runtime, whereas that's easy to conflate with package config settings, which get none of the same benefits (either the env var normalization or the --prop_name args). I just spent 20 minutes fighting it and gave up.

Some notes:

If my package contains:

"scripts": {
    "scripty": {
      "parallel": false
    }
}

Then as you would hope, process.env.npm_package_config_scripty_parallel is set to 'false'. But once it's set in the package json, there's no apparent way to override it dynamically, making it just as blunt an instrument as always using an arbitrary ENV var.

That is to say: npm_package_config_scripty_parallel=true npm run foo will still set the variable to 'false', and NPM_PACKAGE_CONFIG_SCRIPTY_PARALLEL npm run foo will set the var in upper case, without the case-insensitive translation suggested by the docs.

from scripty.