cross-env integration

[franklin-ross]

Create either a branch of cross-env, or a reference implementation which re-implements it's functionality based on this project.

I'm very keen not to break existing projects using cross-env though, so there may be some interesting cases which come up as part of this.

Earlier, related conversation happened here: kentcdodds/cross-env#219.

[yinzara]

In #219 branch of cross-env, I abstracted away the environment replacement. We may be able to use that as a base to call the new bash-env-parser library.

The requirement would be for the "env replace" function to have an method of doing the replacement with "%EnvVarName%" to deal with existing functionality.

[franklin-ross]

OK great, yeah I was wondering whether some of that might be reusable.

There's 2 thoughts in my mind for how to go about the "env replace". You'll have a better idea of the cross-env internals than me, but right now I believe it does what you're suggesting above, basically converting bash style environment variables into whatever's right for the current platform. That's still an option going forward, but it doesn't really work with default values, right? Because there's no equivalent syntax in cmd? So then you have to do an actual value replacement if you need the default, otherwise you convert the environment variable syntax?

So I was going to try making 2 versions:

• The first is your idea above, replace any defaults, but otherwise translate the syntax. The upside is that it matches what cross-env does already, the downside is that it seems like a bit of a hybrid.
• The second is to completely convert the command string into it's final value based on bash's rules, completely sidestepping any platform specific stuff. The result would then be passed to a shell with all values completely substituted already.

I'd probably rather the second because it's totally under control, but it depends whether there are any issues matching existing cross-env behaviour. We'll just have to be really strong on the tests and make a call.

[yinzara]

The problem with the second option (which I probably prefer anyway) is that it breaks the current behavior of cross-env and would probably require a major version change.

I can't for the life of me come up with a reason you would put the CMD style syntax in the cross-env other than an EXTREMELY rare case where you wanted to execute a command that may spawn other processes with environment variable values that may change during the execution but I can't even come up with any viable reasons to do that in a way that could work cross platform. I can come up with ones that might work in bash but definitely wouldn't translate to windows.

[franklin-ross]

Yeah that was my thought too. I'm sure there are some obscure cases, but they'd already be broken either way by adding default values, and would quite likely be platform specific anyway, so I don't know. I mean, you already have to escape environment variables if you want to pass them into an inner command.

I don't think it's hard to do both, and then we can just try our best to think of pathological cases and see whether they're different from current cross-env.

[yinzara]

Any updates on this? I kinda wanted to use this in another project (other than cross-env)

[franklin-ross]

Ahoy, sorry I haven't been checking my inbox much recently.

So I think the next step is for me to open a PR in cross-env with this library integrated into the environment variable parsing code. It should be good to handle everything, from I can tell, so I just need to get it in and see whether it's fit for purpose, and then tweak it as needed.

[franklin-ross]

Apologies that it's taken so long @yinzara, I've got a bad habit of getting things to 80% then getting busy with other things, but I've been meaning to push this all the way through.

In terms of using it for another project, I'm half way through a bit of a simplification pass, but otherwise I think it's fairly stable. What kind of project are you going to be using it in? I'd consider it to be in a sort of alpha state right now, so just keep that in mind, but it would be good to have someone else use it and see whether there are any sharp edges on it.