Environment variable handling in a crossplatform way

[matyasf]

Environment variables are passed differently in Windows and unix systems, so we cannot write scripts easily that run on both platforms. It would be very nice if concurrently would include such functionality, so we don't need to write horrors like

concurrently "cross-env FIRST_ENV=one my-program arg1" cross-env ANOTHER_ENV=two my--other-program arg3

[milahu]

so we don't need to write horrors like

whats so horrific about cross-env KEY=val cmd? how should concurrently do that better? with --env <key>=<val> arguments ...?

[gustavohenke]

Keen to hear more thoughts. I'm not too strong either way.

[matyasf]

whats so horrific about cross-env KEY=val cmd?

That I need 2 packages (and their zillions of dependencies) just to run 2 executables in parallel properly.

how should concurrently do that better? with --env = arguments ...?

Yep, that would be great, for example:

concurrently "my-program arg1" "my-other-program arg2" --env1=FIRST_ENV=one  --env2=ANOTHER_ENV=two

[kotx]

Though --env1 and --env2 etc don't seem too elegant, I'm in favor of a feature like this. +1

[milahu]

this works already

concurrently "cross-env FIRST_ENV=one my-program arg1" cross-env ANOTHER_ENV=two my--other-program arg2

possible solutions

1. concurrently "my-program arg1" "my-other-program arg2" --env1=FIRST_ENV=one --env2=ANOTHER_ENV=two

2. concurrently --env=FIRST_ENV=one "my-program arg1" --env=ANOTHER_ENV=two "my-other-program arg2"

3. concurrently --parse-env "FIRST_ENV=one my-program arg1" "ANOTHER_ENV=two my--other-program arg2"

4. concurrently "FIRST_ENV=one my-program arg1" "ANOTHER_ENV=two my--other-program arg2"

[kotx]

I'd prefer 2nd option, the 3rd and 4th could likely break or produce unintended behavior.

[milahu]

we can implement both 2 and 3 with backward compatibility (default is --no-parse-env)

[matyasf]

cross-env is no longer developed anymore. Is it OK if I try to submit a PR for this issue?

[gustavohenke]

I'd be open to see a PR for this, but i prefer to see it implemented initially via a --env flag that passes the vars to every command.

Parsing env vars from each input is probably too much at this stage and requires a lot more thought. E.g. should this work? concurrently "SOME_VAR=1 npm:watch"

Interleaving commands and flags should probably also be out of the initial scope, e.g. concurrently "echo bla" --env SOME_VAR=1 "echo hello".

[atomkirk]

are you open to a PR that lets us pass a .env file? Is there a reason not to have concurrently look for and load a .env automatically?