4 ms·

Since it seems the devs are here answering questions: Which lightweight shell will be used on Windows? Does it also bundle standard unix tools (if a script pip

by jclay 8y ago

Since it seems the devs are here answering questions: 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)? How will paths be translated on Windows? I’ve attempted something similar recently and had to do a fair amount of regex magic + using cygwins built in path translation utility to preprocess commands. Curious to see if there’s a better way to solve that.

arcatek 8y ago
> 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.
- exogen 8y ago
  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? p.s. I love Yarn :)
  - arcatek 8y ago
    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 ;)
    - exogen 8y ago
      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. :(

by jclay 8y ago

arcatek 8y ago

> 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.

exogen 8y ago
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? p.s. I love Yarn :)
- arcatek 8y ago
  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 ;)
  - exogen 8y ago
    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. :(