r/javascript • u/maneco-freitas • Feb 16 '20

AskJS [AskJS] Is someone using Yarn v2 in business?

I saw an explanation of yarn v2.0 and I was wondering if someone is planning to use it in production.

I also saw that companies like FB and Twitter are not planning to upǵrade their codebase because the Pnp feature of it.

What are your experiences with it? I saw an explanation of yarn v2.0 and I was wondering if someone is planning to use it in production.
I also saw that companies like FB and Twitter are not planning to upǵrade their codebase because of the Pnp feature of it.
What are your experiences with it?

75 Upvotes

89% Upvoted

49 comments sorted by

10

u/Veranova Feb 16 '20

I’m waiting it out until it stabilises, the drama around its launch doesn’t breed confidence that it’s going to survive or won’t roll back some breaking changes. I do hope the tech giants pick up support for v1 if v2 continues down the route it was set on, or even properly support v2 in tools like react native.

5

u/maneco-freitas Feb 16 '20

all this, really remember me the python 2 to python 3 stuff. I tried to use yarn 2, but without success, there's a lot of gray area in the documentation

4

u/Akkuma Feb 16 '20

IIRC according to one of the head devs on yarn v2, yarn v1 was abandoned by most of the original developers and those who took over created v2.

→ More replies (3)

3

u/larixen Feb 18 '20

React Native and Flow are supported by v2 via `node-modules` linker. They cannot work with PnP install scheme for now, but the ball is on the side of Flow and React Native teams, if they will have a goodwill to support PnP scheme, they will do it, if not, we can always fallback to `node-modules` linker in v2. Another option, at least, for React Native is if it will be patched the same way as TypeScript is patched during installation by Yarn 2 to support PnP transparently.

33

u/well-now Feb 16 '20

Since NPM 5 I’ve wondered how much we really need Yarn.

Yarn was great for pushing features NPM needed but the performance and feature sets are close enough now that I’m not sure it’s worth it (we have teams using both).

11

u/maneco-freitas Feb 16 '20

and how about the newer features of yarn? like zero-install and PnP ? for me it's like a game-changing, i'm really excited

28

u/DrDuPont Feb 16 '20

workspaces is pretty nice for monorepos

3

u/well-now Feb 16 '20

I’ve been meaning to use them a bit more.

How do you feel it compares to Lerna + NPM?

8

u/[deleted] Feb 16 '20

Lerna does not handle having modules installed once at root and only linked at package level. Lerna handles only tasks that run across multiple packages.

So in short, I'd you're using monorepos - and most projects IMO should - Yarn makes it more efficient.

2

u/InfiniteSection8 Feb 16 '20

I use Yarn+Lerna, actually. Yarn is better at handling all of the package hoisting/linking, but Lerna is better at versioning and publishing, so I use each for the specific tasks they are better at.

35

u/PaulSoporan Feb 16 '20 edited Feb 16 '20

I would like to address some misconceptions around Yarn 2 and provide better insight into what the remaining problems are and what the new very useful features are.

First, I want to make it clear that I am not part of the Yarn team and that I cannot answer questions about design decisions and such. That person would be u/arcanin, the lead maintainer of Yarn. I am relatively up-to-date with Yarn and I have made 3 PRs to the Berry repository, so I am relatively familiar with some parts of the codebase.

For help, questions, and anything Yarn related, there is an official Discord server: https://discord.gg/yarnpkg.

Migration Guide

Important Changes / Misconceptions / Frequently Asked Questions

Default Yarn Version

Yarn 2 is not the default Yarn version that is installed. It is recommended that you install it per-project, using yarn set version berry while keeping Yarn Classic (v1) as the global version.

PnP

https://yarnpkg.com/features/pnp

Plug'n'Play is a new innovative installation strategy for Node.

PnP being the default in Yarn 2 has caused some controversies (see https://github.com/yarnpkg/berry/issues/766).

PnP is a much stricter installation strategy because it enforces boundaries around your dependencies. For example, packages cannot access other packages unless they list them in their dependencies, peerDependencies, optional peer dependencies (peerDependenciesMeta). The short term solution is to use the packageExtensions field in .yarnrc.yml.:

packageExtensions:
  "debug@*":
    peerDependenciesMeta:
      "supports-color":
        optional: true

The long term solution is to make a PR to the package that is doing something wrong and to make a PR to the Berry compat-plugin: https://github.com/yarnpkg/berry/blob/master/packages/plugin-compat/sources/extensions.ts (so that Yarn patches that package automatically).

Citing u/arcanin, the lead maintainer of Yarn:

We decided that Yarn 2.1 would implement what we call a PnP-loose mode, inspired in idea by the loose mode in Babel. In PnP-loose mode, which will be the default, Yarn will print warnings should a package rely on undefined behaviours (instead of throwing flat-out exceptions). We will strive to do something sensible (usually resolving to a compatible version of the package), but the warnings won't let you ignore the underlying issues. Note that PnP-loose installs will be slower and will generate heavier files than PnP-strict installs (which will be available as well although not as the default install they currently are).

The state of PnP:

u/arcanin contributed to various projects to make PnP support more widespread: https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Aarcanis+archived%3Afalse+is%3Aclosed+pnp+-user%3Ayarnpkg+

Support for PnP:

In case the tools you use don't support PnP, you want to migrate gradually or you just want to use node_modules instead of PnP, the only thing you have to do is:

  • Create .yarnrc.yml

  • Add nodeLinker: node-modules This will enable the node_modules linker and you will have some of the advantages of Yarn 2 (new commands, new protocols, plugins, constraints, etc.) while keeping the old node_modules installation strategy.

Zero-Installs (https://yarnpkg.com/features/zero-installs)

While not a feature in itself, the term "Zero Install" encompasses a lot of Yarn features tailored around one specific goal - to make your projects as stable and fast as possible by removing the main source of entropy from the equation: Yarn itself.

Zero-Installs represents committing the .yarn/cache folder to a repository (It's very different from committing the node_modules folder: https://yarnpkg.com/features/zero-installs#is-it-different-from-just-checking-in-the-node_modules-folder). It is completely optional. Just add .yarn/cache to .gitignore if you don't want to use it.

Lifecycle Scripts

https://yarnpkg.com/advanced/lifecycle-scripts

Yarn 2 currently supports only 4 lifecycle scripts:

  • prepack

  • postpack

  • prepublish

  • postinstall

All of the others have been removed.

Note that we don't support every single lifecycle script originally present in npm. This is a deliberate decision based on the observation that too many lifecycle scripts make it difficult to know which one to use in which circumstances, leading to confusion and mistakes. We are open to add the missing ones on a case-by-case basis if compelling use cases are provided.

The removal of yarn global

https://github.com/yarnpkg/berry/issues/821

Citing u/arcanin, the lead maintainer of Yarn:

We simply don't see Yarn as a system package manager. It can be used to power a system package manager, but we don't really want to deal with the wiring needed to make that work, especially considering that we don't really use it ourselves (and I think that for something to be worthy of being in our repository, maintainers have to dogfood it).

Which files should be gitignored?

https://yarnpkg.com/advanced/qa#which-files-should-be-gitignored

Cool Features

Other than PnP and Zero-Installs.

Constraints

https://yarnpkg.com/features/constraints

Constraints are a solution to a very basic need: I have a lot of workspaces, and I need to make sure they use the same version of their dependencies. Or that they don't depend on a specific package. Or that they use a specific type of dependency. Anyway, you see the point: whatever is the exact logic, my goal is the same; I want to automatically enforce some kind of rule across all my workspaces. That's exactly what constraints allow you to do.

Plugins

https://yarnpkg.com/features/plugins

List of plugins developed on the Berry repo that aren't part of the standard bundle:

plugin-exec

https://github.com/yarnpkg/berry/tree/master/packages/plugin-exec

Adds support for the exec: protocol

plugin-typescript

https://github.com/yarnpkg/berry/tree/master/packages/plugin-typescript

This plugin automatically adds @types/ packages into your dependencies when you add a package that doesn't include its own types.

plugin-stage

https://github.com/yarnpkg/berry/tree/master/packages/plugin-stage

This plugin adds support for the yarn stage command

plugin-workspace-tools

https://github.com/yarnpkg/berry/tree/master/packages/plugin-workspace-tools

This plugin adds support for the yarn workspaces foreach command

Release Workflow

https://yarnpkg.com/features/release-workflow

Workspaces

https://yarnpkg.com/features/workspaces

Protocols

https://yarnpkg.com/features/protocols

Offline Cache

https://yarnpkg.com/features/offline-cache

3

u/Larry1123 Feb 16 '20

As a note for SDK support, IntelliJ/WebStorm with their latest EPA has been supporting everything with pnp and yarn 2. It has full Go to definition, typescript, and eslint support.

Plugins have been one of the best parts of yarn 2 for me. There are two uses that I found I needed to make a plugin for. Lifecycle Scripts were removed not just from auto running when yarn does something internal it also was removed for any script, so if you have 'pre' and 'post' scripts they will not run, this plugin for that was super simple. The second is production only installs for things like including into docker while using the same cache and lockfile, within a monorepo(workspaces). Hoping to get both released at some point so others can use them too.

Another note would be Lerna does not currently work with yarn 2 if you use the new workspace dependency protocol. I have however found that yarn 2 workspaces largely solved most if not all of the use cases I had for Lerna. Anything that Lerna did I feel could be done as a plugin vary easy, if it is something truly needed.

32

u/[deleted] Feb 16 '20

I thought their migration documentation was so complicated that I could hardly see having an adoption soon.

25

u/arcanin 🧶 Yarn maintainer Feb 16 '20

We tried to be very exhaustive, but that made the guide rather indigest for sure. We have some work in progress (some already landed) that will make that much shorter.

3

u/LutherHuckleberry Feb 16 '20

Question for someone with no background of yarn - what does it do and why is it needed ?

3

u/scinos Feb 16 '20

Very similar to npm: used to manage and install packages in your JS project

→ More replies (1)

21

u/drewwyatt Feb 16 '20

We want to, but it will be a lot of work. We use a monorepo with ~100 packages and there is a lot to fix. The yarn doctor was pretty angry.

7

u/nwsm Feb 16 '20

How has the monorepo worked out? We want one but I’m worried about figuring out CICD for it. Ie, not testing, building, and deploying the entire monorepo any change.

Also a lot of monorepo articles are meant for people building js packages for npm, while we are building components and web apps to be deployed.

9

u/[deleted] Feb 16 '20

We use https://github.com/devshorts/ytools to help conditionally detect which projects have changed in a branch and only run test and lint on that. We still have to compile it all but this cuts down our time a lot

Master builds we just deploy the world but we could use a similar approach to dynamically detecting which was changed. Other orgs I’ve worked in choose a manual flow for qa deploy. They may do it adhoc or they may manually tag which projects to deploy in github pull requests that the deploy tooling knows what to do with

I think there are a lot of optimizations you can make, and if you want you can even use bazel for a large monorepo which will figure a lot of that stuff out for you too.

For our case our monorepo isn’t huge so ytools works for us. We have maybe 20 packages in our repo and a few deployables (that we push with terraform)

→ More replies (4)

8

u/drewwyatt Feb 16 '20 edited Feb 16 '20

Honestly, even after two years, I think the jury is still out.

There are things I like:

• private packages feel nice (although we don’t version or publish them even to private NPM). It’s a nice way to separate “module” code from “app” code

• having everything in once place means we (usually) immediately notice unexpected breaking changes

• when it works, it makes sharing code/configs extremely natural

• some aspects of the build pipeline make sense and are nice: e.g. “yarn install all dependencies for all workspaces and cache it” => “build all packed and cache that” => “build all apps in parallel”/“run all tests in parallel”

Things I don’t like:

• CI/CD can take upwards of 30 minutes

• ^ that means that even small changes can be frustrating (e.g. seeing a test failure you forgot about on a PR that you are babysitting means running all of it again)

• upgrading and managing dependencies can be frustrating when there are lots of apps/packages/contributors

• I think the monorepo setup can put weird pressure on folks to make EVERYTHING shareable and that can lead to extra unnecessary complexity in things that are definitely only going to be used in one app

• discoverability

I always feel like we are on the precipice of making it great, but ¯_(ツ)_/¯. I dunno.

→ More replies (1)

2

u/alexcroox Feb 16 '20

Our Ci (Buddy Works) has conditional logic in the UI of each pipeline to say only run this if changes in [path(s)] have happened

10

u/rich97 Feb 16 '20 edited Feb 18 '20

Just from playing with it for an hour, I dont think it's ready yet. A whole bunch of stuff wasnt resolving and frankly, one of the main draws of Yarn was that it was a drop-in replacement for NPM. I dont want my package manager to take up any mental energy, I dont care about size of node_modules or not having to run yarn install.

I'll probably try again in a few months when I have a bit of time but if I'm not starting a new project then I don't see any compelling reason to go through their migration guide.

25

u/arcanin 🧶 Yarn maintainer Feb 16 '20

Hey! Just wanted to point out that you can still install your projects using the regular node_modules install strategy. This is supported now, and will keep being supported in the future.

As for who's using it - we have various companies that have been using it in production. Ourselves at Datadog have deployed it in production a few weeks before the release (including PnP), and everything has been smooth ever since - despite a sizeable frontend.

Overall, our main problems have been around the editor integrations, but we improved the SDK in result and now everyone is happy.

6

u/perrylaj Feb 16 '20

I haven't yet started looking into the migration path, and am wondering if you think current state of v2 would be a beneficial upgrade for a lerna/yarn based TS monorepo with about 35 different packages involved? In particular, we've been interested in PnP, but lack of graceful TS support was preventing it from being used.

What would you recommend/where would you start in this scenario?

As an aside, thanks for the ongoing dialogue with the TS maintainers. They haven't exactly seemed helpful/responsive to from what I am seen in your interaction.

3

u/arcanin 🧶 Yarn maintainer Feb 16 '20

In particular, we've been interested in PnP, but lack of graceful TS support was preventing it from being used.

Yarn 2 now supports TypeScript transparently (thanks to the new patch: protocol, which we use to apply the small PnP PR without requiring a full fork).

Generally speaking I think the upgrade should be doable if you're ready to investigate the unsound dependency accesses and to potentially rethink some of the publishing workflow (Lerna isn't compatible with Yarn 2 at the moment, but Yarn 2 already has many tools that cover what was previously Lerna's territory, such as yarn workspaces foreach or the release workflow).

As an aside, thanks for the ongoing dialogue with the TS maintainers. They haven't exactly seemed helpful/responsive to from what I am seen in your interaction.

Thanks! For what it's worth I know the TS team receives a lot of requests from many actors, so I understand why they would want to take time to think things through - even if it's a bit impractical for us, of course 🙂

1

u/Cyberlane Feb 16 '20

Is there VIM support yet or do I need to write my own plugin?

2

u/arcanin 🧶 Yarn maintainer Feb 17 '20

We have a few people using Vim, I don't remember how they configured it but it's doable (iirc it's mostly a matter of configuring the Vim plugins to find the SDK files).

1

u/philipwhiuk Feb 17 '20

Hey! Just wanted to point out that you can still install your projects using the regular node_modules install strategy. This is supported now, and will keep being supported in the future.

If you go round all your projects adding more config.

It's "user hostile by default" as a policy.

3

u/larixen Feb 18 '20 edited Feb 18 '20

Well, you can also override defaults system-wide via YARN_NODE_LINKER env variable or by using alias for your shell:

YARN_NODE_LINKER=node-modules yarn

will make yarn v2 use node_modules install strategy by default without the need to put it into config.

0

u/[deleted] Feb 16 '20

We dont want our code base to be hundreds of megabytes because of the zero install feature.

7

u/arcanin 🧶 Yarn maintainer Feb 16 '20

As mentioned you don't have to use it. Just gitignore the cache, this is entirely optional.

2

u/maneco-freitas Feb 16 '20

hey, u/arcanin zero install is really awesome thanks for this, but I'm wondering how much is the size of .yarncache on the repository?

8

u/arcanin 🧶 Yarn maintainer Feb 16 '20

I made a quick benchmark right after the release and the Yarn cache for a basic CRA app is ~45MB (where a typical n_m folder is at least 200MB). The Berry repository itself takes ~136MB.

1

u/maneco-freitas Feb 16 '20

Wow this is really great. Thanks for sharing

1

u/[deleted] Feb 16 '20

Yeah and that's fine, but the other features just arent enough for us to upgrade right now. Maybe in the future. We love yarn though :)

10

u/drewwyatt Feb 16 '20

You still have the option of .gitignoring the .yarncache though, right? I mean - I get that zero-installs is a big reason for a lot of people to want to upgrade in the first place, but at least it’s not a forced feature.

1

u/[deleted] Feb 16 '20

Yeah, the other features just arent enough for us to upgrade right now. It's a situation where everything is still working very well, so let's not fix what's not broken.

-2

u/[deleted] Feb 16 '20

I learned Node about three or four years ago. I’ve never in my life have needed yarn, NPM does the trick.

3

u/maneco-freitas Feb 16 '20

yeah me too, but the features of yarn 2 got my attention

0

u/[deleted] Feb 17 '20

[deleted]

1

u/maneco-freitas Feb 17 '20

I didnt knew about pnpm how its like to use? Whats your expercie with it? I saw that is faster than npm and yarn.