When a user sets environment variables, those should be extending the current ones, as opposed to redefining them. Just like the default behavior of Execa (extendEnv: true.
Reasons:
This is what users most likely expect.
This is how shells behave when running EXAMPLE_ENVVAR=value binary arg....
This is how environment variables were designed: child processes inherit from their parent.
When running a binary by its filename (as opposed to its file path), the PATH environment variable is needed. If the env option was to override the current environment variables (including PATH), most users will then get a ENOENT error, which might confuse them. Source: it just happens to me and it took me 30 seconds to realize what was going on.
Also, this can be implemented in very few bytes: {...process.env, ...options.env}.
I am also thinking that we don't need to expose any extendEnv option like Execa, since that's usually not needed, and in the spirit of keeping things small.
When a user sets environment variables, those should be extending the current ones, as opposed to redefining them. Just like the default behavior of Execa (
extendEnv: true
.Reasons:
EXAMPLE_ENVVAR=value binary arg...
.PATH
environment variable is needed. If theenv
option was to override the current environment variables (includingPATH
), most users will then get aENOENT
error, which might confuse them. Source: it just happens to me and it took me 30 seconds to realize what was going on.Also, this can be implemented in very few bytes:
{...process.env, ...options.env}
.I am also thinking that we don't need to expose any
extendEnv
option like Execa, since that's usually not needed, and in the spirit of keeping things small.Thoughts?