Yarn's Future – v2 and beyond

Very happy to see yarn.lock will finally be a proper format that won&#x27;t need its own parser. YAML subset is a pretty good choice, though I think canonicalized, indented JSON would be a better choice for this use case. Incidentally that&#x27;s what npm uses as lockfile, I wonder if there&#x27;s room to have the two package managers share the format (or even share the file itself).<p>Very excited to see shell compatibility guarantee in scripts as well. Using environment variables in scripts is a pain right now.<p>Finally one of the biggest news is the switch from Flow to Typescript. I think it&#x27;s now clear that Facebook is admitting defeat with Flow; it brought a lot of good in the scene but Typescript is a lot more popular and gets overall much better support. Uniting the JS ecosystem around Typescript will be such a big deal.

&gt; The codebase will be ported from Flow to TypeScript. To understand the rational please continue reading, but a quick summary is that we hope this will help our community ramp up on Yarn, and will help you build awesome new features on top of it.<p>Another major project moving from flow to typescript

&gt; The log system will be overhauled - one thing in particular we&#x27;ll take from Typescript are diagnostic error codes. Each error, warning, and sometimes notice will be given a unique code that will be documented - with explanations to help you understand how to unblock yourself.<p>Why do programmers love error codes? As an end user, they are useless indirection to me and the only way this would even be tolerable is if the explanation was printed directly next to the error code, so why bother? Is it code quality, since you don&#x27;t have to write a long error message when you emit a similar error? But doesn&#x27;t that have the drawback of encouraging error code reuse when it might not be appropriate?<p>[append]<p>Thanks for the replies! I guess I could understand error codes for search ability that also provide information about the problem specifics.<p>Counterexample:<p><pre><code> $ yarn add foo Error YARN1001: Incompatible peerDependencies. $ yarn explain YARN1001 # Some longer text about how two of my modules have # incompatible peerDependencies </code></pre> Better example:<p><pre><code> $ yarn add foo Error Yarn1001: Incompatible peerDependencies. * my-package@1.0.0 |-* foo@1.0.0 |-* bar@1.0.0 |-* left-pad@1.0.1 (peerDependency of bar@1.0.0) |-* left-pad@0.9.0 (peerDependency of foo@1.0.0) $ yarn explain YARN1001 # Some longer text about how two of my modules have # incompatible peerDependencies</code></pre>

I’m glad that Yarn will continue. Npm has improved, but it’s still less pleasant to work with than yarn (which basically always does what I expect, not so for npm).

The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious.<p>The move towards TypeScript &#x27;winning&#x27; has been fast, and to everyone&#x27;s benefit.

I&#x27;ve got to say I&#x27;m not a big fan of some of these changes and I think they&#x27;re biting off more than they can chew.<p>&gt; 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&#x27;ll be used by default.<p>&gt; 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.<p>If you use either of these features your package.json will no longer work with NPM. Maybe they should call it yarn-package.json?<p>&gt; 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&#x27;re interested into implementing PHP, Python, Ruby package installers without ever leaving Yarn, please open an issue and we&#x27;ll help you get started!<p>Noooo, god no. Package management is a gargantuan, complicated task, and these languages all have their own solutions already.<p>That being said, it&#x27;s cool that they&#x27;re rewriting it in TypeScript.

There appears to be a real movement to move from Flow to typescript. Is Flow dying?

&gt; your previous yarn.lock will be silently migrated<p>I hope that&#x27;s not <i>that</i> silent, because at that point, everybody who works on that project will have to upgrade as well.<p>That said, shipping the light-weight POSIX-like shell will make it a lot easier for scripts to be multiplatform. That&#x27;s the improvement I&#x27;m looking forward to most.

For the uninitiated &#x2F; confused, this refers to yarnpkg, the JavaScript dependency manager, not (Hadoop) YARN, the cluster manager.

I&#x27;m curious as to why yarn instead of contributing to NPM? I am aware that yarn was the inspiration for many improvements for NPM by providing an alternative, but going forward do we need two systems? Is the plan for yarn to be compatible with NPM and package.json?

The addition of vulnerability scanning was the only reason our company switched back to npm from yarn. Other than that, yarn offers a great experience

&gt; Writing posix command lines inside your scripts field will work regardless of the underlying operating system<p>That is very nice. No need to install other dependencies just to do &#x27;rm -rf&#x27;

Since it seems the devs are here answering questions:<p>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)?<p>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.

If you use the yarn cli and have tried the npm cli recently, why do you still use yarn? Are there big gaps that you find that NPM has failed to close?

If package.json is already in JSON format, why not use the same for yarn.lock? Honest question, there must be a good reason.

serious question, if you are starting a new project today why would you choose to use npm over yarn?

Yarn has over 1500 open bugs. Rather than working on changes, it&#x27;d be nice to stop and address these.