3 ms·

I've got to say I'm not a big fan of some of these changes and I think they're biting off more than they can chew. > Writing posix command lines inside your sc

I've got to say I'm not a big fan of some of these changes and I think they're biting off more than they can chew. > Writing posix command lines inside your scripts field will work regardless of the underlying operating system. This is because Berry will ship with a portable posix-like light shell that'll be used by default. > Scripts will be able to put their arguments anywhere in the command-line (and repeat them if needed) using $@. Similarly, scripts will have access to $1, $2, etc. If you use either of these features your package.json will no longer work with NPM. Maybe they should call it yarn-package.json? > Starting from Berry, we made it an explicit goal that each component of our pipeline can be switched to adapt to different install targets. In a way, Yarn will now be a package manager platform as much as a package manager. If you're interested into implementing PHP, Python, Ruby package installers without ever leaving Yarn, please open an issue and we'll help you get started! Noooo, god no. Package management is a gargantuan, complicated task, and these languages all have their own solutions already. That being said, it's cool that they're rewriting it in TypeScript.

maw 8y ago
I don't see the need for PHP, because composer is one of the few things I like about it. And I don't know enough about Ruby to have an opinion there. But something for Python that actually works? Yes, please!
- nhanb 8y ago
  For python we've been using poetry[1] at work. Dep resolution is a bit slow but otherwise it works well enough, definitely a saner choice than pulling in a completely different stack just for one tool. [1]: https://poetry.eustace.io/ https://poetry.eustace.io/
arcatek 8y ago
> If you use either of these features your package.json will no longer work with NPM. Yes and no. In the case of the `postinstall` script (which might indeed have to run on npm setups) you might want to refrain using those features. In any other case you simply won't use npm if you use them, because those are local scripts that only you and your team will use - and regardless of those features you should all use the same package manager anyway. > Noooo, god no. Package management is a gargantuan, complicated task, and these languages all have their own solutions already. We won't spend much time on it ourselves - as you mentioned other solutions exist and we have to pick our fights. Still, I believe this is a necessary move if we want to make our codebase clear and easy to contribute to. It's not so much about Yarn supporting everything than it is about making sure that we don't end up with a monolithic system hard to maintain.

maw 8y ago

I don't see the need for PHP, because composer is one of the few things I like about it. And I don't know enough about Ruby to have an opinion there. But something for Python that actually works? Yes, please!

nhanb 8y ago
For python we've been using poetry[1] at work. Dep resolution is a bit slow but otherwise it works well enough, definitely a saner choice than pulling in a completely different stack just for one tool. [1]: https://poetry.eustace.io/ https://poetry.eustace.io/

arcatek 8y ago

> If you use either of these features your package.json will no longer work with NPM. Yes and no. In the case of the `postinstall` script (which might indeed have to run on npm setups) you might want to refrain using those features. In any other case you simply won't use npm if you use them, because those are local scripts that only you and your team will use - and regardless of those features you should all use the same package manager anyway. > Noooo, god no. Package management is a gargantuan, complicated task, and these languages all have their own solutions already. We won't spend much time on it ourselves - as you mentioned other solutions exist and we have to pick our fights. Still, I believe this is a necessary move if we want to make our codebase clear and easy to contribute to. It's not so much about Yarn supporting everything than it is about making sure that we don't end up with a monolithic system hard to maintain.