> Which lightweight shell will be used on Windows? Does it also bundle standard unix tools (if a script pipes to grep or less for example)?
It will be in-house, and very basic. We don't intend to rewrite bash, just to provide the basic experience that is usually needed when adding script into the `scripts` field. For more complex needs we'll simply offer a way to opt-out and use the native shell, or to call Node scripts.
> How will paths be translated on Windows?
The current Yarn tries to do this by using the `path` native module. It's quite error-prone since backslashes tend to appear in the worst possible places. For the v2 I plan to work with all paths in a posix style, and convert them into Windows paths right before they reach the filesystem (which is similar to what Cygwin does, as you mentioned). It would be a bit slower on Windows, but massively simpler in the codebase.
I'm assuming that lifecycle scripts (and scripts called by lifecycle scripts) in particular will still need to use common Windows-supported syntax? Even if the devs of the package are guaranteed to be using Yarn, people installing the package might still be using npm. So I assume some caveats apply to some scripts, right?
The `postinstall` scripts would likely be better off without using those features, indeed. But in the end, your packages would be better off without `postinstall` scripts anyway ;)
Yeah I don't recommend `postinstall`, but `prepare` (and all the potential build-type scripts it could run) is actually useful (esp. for allowing people to install from unpublished versions via git), and would need special consideration. :(
It will be in-house, and very basic. We don't intend to rewrite bash, just to provide the basic experience that is usually needed when adding script into the `scripts` field. For more complex needs we'll simply offer a way to opt-out and use the native shell, or to call Node scripts.
> How will paths be translated on Windows?
The current Yarn tries to do this by using the `path` native module. It's quite error-prone since backslashes tend to appear in the worst possible places. For the v2 I plan to work with all paths in a posix style, and convert them into Windows paths right before they reach the filesystem (which is similar to what Cygwin does, as you mentioned). It would be a bit slower on Windows, but massively simpler in the codebase.