11 ms·

Yarn 3.0

154 points by Jowsey 5y ago

oefrha 5y ago
Anyone has seen stats on yarn 2 uptake? I’m still on yarn 1 and I know I’m far from the only one.
- mrRandomGuy 5y ago
  I tried updating my teams frontend pipelines from Yarn 1 to Yarn 2 since there seemed to be some significant performance improvements. I spent some time trying to understand why I needed a third party plugin to run the equivalent of `yarn install --production` I just said fuck it and I'll let the frontend team figure this shit out. So yeah, I wouldn't be surprised if the Yarn 1 usage is significantly higher than Yarn 2
- jitl 5y ago
  The only project of mine where I use Yarn 2 was one where arcanist, the yarn2 maintainer, added it himself. Otherwise, I use yarn@1 which requires significantly less brain cells than following yarn2 opinions/changes/plugins/installing
- ninjaoxygen 5y ago
  We also remained on Yarn 1 because developing packages using the workspaces feature is really nice. We did make an attempt at moving to Yarn 2, it did not work out well. At that time (probably 12 months ago or more) lots of upstream packages had broken package.json files, we never managed to fix them all. Lots of things with React were a bit screwy too!
- theshrike79 5y ago
  Still on Yarn 1. Looked at Yarn 2, saw that it was a ton of work (compared to our npm -> yarn 1 transition) and said sod it. Let's see if Yarn 1 -> 3 is any easier.
- gregors 5y ago
  Still on Yarn 1 with no plans on upgrading anytime soon.
nicoburns 5y ago
I'd be interested to know what HN's experience with Yarn 2 has been. Yarn 1 was compatible with NPM, so switching was easy, but Yarn 2 seems to need explicit support in a lot of cases. Had anyone found significant benefits from switching to yarn 2? And conversely, has anyone had any issues with this? EDIT: It seems that there is also a 3rd option: pnpm. Experiences with pnpm would also be welcomed.
- crubier 5y ago
  We have a monorepo with 200packages. NPM install times were longer than 1hour. Unusable. Yarn v2 took this down to 20 seconds. Yes, around 200x faster. They just are not comparable on that aspect. The issues we had are with some packages who don’t list their peerDependencies correctly, or which assume the file structure of node_modules will be the one made by npm. But yarn has improved and these obstacles are much easier now.
  - dmitryminkovsky 5y ago
    That is so appealing... I don't have a monorepo with 200 packages but I do `yarn install` in a Dockerfile and if something changed that uncached that line, the whole thing can take 10 minutes or more to download, unpack, install. Would love to try Yarn 2 (3, now, I guess) when I can. Does Rome use yarn? Anyone using Rome in production?
    - city41 5y ago
      I haven't actually used Rome, but their installation guide mentions both yarn and npx, so that possibly means Rome is agnostic on them https://rome.tools/#installation-and-usage https://rome.tools/#installation-and-usage
    - tuxie_ 5y ago
      If you are on mac, this is a known docker issue because in non-Linux systems fs access is virtualized (docker runs on an Ubuntu running on a vm). Becomes pretty unusable.
bassman9000 5y ago
> Breaking Changes > Node 10 isn't supported anymore. 10 is LTS
- akmittal 5y ago
  Not really, it was supported till April, 21 https://github.com/nodejs/Release https://github.com/nodejs/Release
- staticassertion 5y ago
  Is there somewhere that actually talks about LTS releases? I'm trying to find when it's EOL and I'm getting mixed information - one page said it was April 2021, you're saying it's still LTS?
  - nicoburns 5y ago
    https://nodejs.org/en/about/releases/ https://nodejs.org/en/about/releases/
    - staticassertion 5y ago
      Thanks, I don't use nodejs much so I tried Google'ing around and got tons of garbage results.
  - shaicoleman 5y ago
    There's also the handy endoflife.date website https://endoflife.date/nodejs https://endoflife.date/nodejs
- kyrra 5y ago
  https://nodejs.org/ru/blog/release/v10.13.0/ https://nodejs.org/ru/blog/release/v10.13.0/ > This release marks the transition of Node.js 10.x into Long Term Support (LTS) with the codename 'Dubnium'. The 10.x release line now moves in to "Active LTS" and will remain so until April 2020. After that time it will move in to "Maintenance" until end of life in April 2021. Node 10 is past EoL at this point. 12 and 14 are the current LTS releases: https://nodejs.org/en/about/releases/ https://nodejs.org/en/about/releases/
ChicagoDave 5y ago
Why is is still master and not trunk?
- bovermyer 5y ago
  "trunk" is a relic of the bad old days and reminds me of Subversion. That naming convention needs to stay dead.
  - ChicagoDave 5y ago
    I meant "main": Github: "Starting next month, all new source code repositories created on GitHub will be named "main" instead of "master" as part of the company's effort to remove unnecessary references to slavery and replace them with more inclusive terms. Teams need tools to help them collaborate and stay productive while remotely working."
    - InGoodFaith 5y ago
      > all new source code repositories keyword there being "new"
    - bovermyer 5y ago
      Fair enough. The "main vs master" argument has been done quite a lot lately, and I'm not going to weigh in on it here. But it seems a little... tangential... to argue about branch naming in this context, doesn't it?
      - ChicagoDave 5y ago
        Honestly my dry sense of humor took a swing and missed. Bigly.
- deleted 5y ago
  [deleted]
- ComputerGuru 5y ago
  Can you go bike shed somewhere else?
paxys 5y ago
Still can't believe they messed up Yarn so bad with v2. It was all set to replace npm, and now isn't anywhere in the picture.
- moretti 5y ago
  yarn 2 solved real problems with zero install and advanced PnP. Maybe the only problem was that it was released too early, wasn't mature enough when it came out. Now it's just better than v1 and npm, works particularly well on large mono repos where upgrading a package can often break other modules due to how node_modules hoisting works.
  - rudian 5y ago
    The problem with Yarn 2 is that it wasn’t Yarn. You can’t change the whole thing and keep the same name. They thought people would just keep using Yarn out of inertia. That’s not how it works.
    - mbStavola 5y ago
      That's what the "V2" signifies: a major, (potentially) breaking change. I'm not surprised nor upset that V2 is radically different. It's all in the versioning scheme!
      - buu700 5y ago
        Eh. They're allowed to do that as per a literal definition of semver, but they turned it into a completely different tool with completely different usage patterns and use cases. It's one thing to have to make some small tweaks to handle an isolated breaking change in a dependency. It's another matter entirely to have a perfectly good core part of your stack deprecated out of the blue and told that you need to rewrite every line of code that it touches. I see this as analogous to the Angular 2 situation, except that Google actually did a good job maintaining Angular 1 (retroactively named "Angular.js") for a number of years afterwards and providing a solid migration path. Everyone who had staked their projects and businesses on the future of Angular 1 was understandably annoyed. All that being said, while I have problems with specifics of their approach, I actually think Yarn made the right call on this. After NPM caught up with v7, it became a bit of a wasted effort to have two redundant projects that were almost drop-in replacements for one another. Yarn staking out a different path at least justifies its continued existence. What I think could have been better is if they'd put an explicit acknowledgement in the migration docs that Yarn 2 wasn't going to be a good fit for all users of Yarn 1, and a recommendation of NPM 7 as an alternative successor to Yarn 1 for such users. An even nicer gesture would have been if they'd written an alternate migration doc for Yarn 1 -> NPM 7.
smashah 5y ago
Wasn't able to get over some of the decisions made on yarn 2. Hopefully yarn 3 is more compatible to a usual npm flow.
xtracto 5y ago
What are the advantages of using Yarn over NPM? It just feels to me that npm does anything that is needed and is available in stuff like ansible-node docker containers. Why should someone who is used to Yarn check Yarn?
- madjam002 5y ago
  For large repos it can be hundreds of times faster than NPM at installs
- Kuinox 5y ago
  We are forced to migrate from npm to yarn: - Somehow one of our dependencies fail to install with old version of npm. - Updating npm to last version fixes this, but on some machines, npm install fails with a 401 error despite having no private registries configured. Still no fixes for this bug after multiples months: - https://github.com/npm/cli/issues/2799 https://github.com/npm/cli/issues/2799 - https://github.com/npm/cli/issues/3284 https://github.com/npm/cli/issues/3284 - There is a lot of other issues on this. Before this, whe had multiples other issues with npm (thats may be still live): - npm is not extensible enough and require a lot of workarounds to be used in safely CI. - There are bugs thats are not fixed for 2 years that make npm ci not working. (https://github.com/npm/cli/issues/289 https://github.com/npm/cli/issues/289) - All bug reports have been closed after a new version release because they have no idea if they fixed a bug or not.
wdb 5y ago
I seem to have issues with using Yarn or NPM v7 with Gitlab NPM private registry. Sadly, I can't use NPM v7 or Yarn yet :(
- john_cogs 5y ago
  GitLab team member here. Can you share a bit more about the issues you are having? Would be happy to try to help resolve or open an issue if its a bug.
  - wdb 5y ago
    Looks like it scheduled for 14.2 (https://gitlab.com/gitlab-org/gitlab/-/issues/330929 https://gitlab.com/gitlab-org/gitlab/-/issues/330929). I hope the `needs` ticket makes it into this release too Keeping my fingers crossed it mades it!
xcambar 5y ago
The single decision from the Yarn team to not offer a reasonable transition path from v1 to v2 was a total blocker for my teams. After trying it on seldected projects, we collectively decided that it was not worth it to follow a project that did not take its users' time seriously, since the migration was so hard. So, yarn@v1 then npm@v7+ for us.
- ironmagma 5y ago
  From the looks of it, the Yarn "team" is mostly one guy. Edit: I retract my previous comment, the additions/deletions count seems misleading. [1] https://github.com/yarnpkg/berry/graphs/contributors https://github.com/yarnpkg/berry/graphs/contributors
  - arcatek 5y ago
    I was the main developer back when the 2.0 was started (so, like, rc.1), but since then we grew and are now a team, with at least four very active contributors of similar expertise. I believe this is the greatest accomplishment of the v2.
- chadlavi 5y ago
  Yep. At least give us some utilities to convert the config files. I'm not hand re-writing all that.
Lammy 5y ago
Don't forget to disable the tracking if you care about that sort of thing: https://yarnpkg.com/advanced/telemetry https://yarnpkg.com/advanced/telemetry `yarn config set enableTelemetry 0` per-project. `yarn config set --home enableTelemetry 0` per-user.
- joshxyz 5y ago
  damn this is not opt-in? lol
tdhz77 5y ago
Yarn had its place. It’s time to move on with npm. The newer version is so much faster and you won’t run into permissions issues like with yarn.
- andrew_ 5y ago
  Forced peerDependency installations in v7 are a deal breaker for me. And as a package author, it's one of the more painful changes to NPM in recent times. Lest we forget the debacle the between prepare, install, prePublish and prePublishOnly that we're still dealing with, and which the other package managers have to contend with.
dstaley 5y ago
One of the biggest things holding me back from transitioning my open source projects over to Yarn and PnP is Dependabot support. I'd even settle for support with the `node-modules` plugin at this point, but GitHub is of the opinion that there isn't much community usage of yarn v2 to warrant the additional development required to support yarn v2+. I'm really glad for all the forward thinking projects like yarn and pnpm are bringing to the node package management space, and I'm also glad to see that npm is listening and taking those advancements into consideration. I'm currently exploring using npm v7's workspaces feature, which was something I originally wanted to use yarn for.
dmitriid 5y ago
So... What exactly is this version, how is it different from yarn 2 that it warrants a major version update (not that I even know what yarn 2 was about), and how does it compare to npm?
andrew_ 5y ago
For my money, I'll take PNPM any day of the week. YMMV it's still faster than any version of Yarn or NPM hands down. https://pnpm.io/ https://pnpm.io/
FractalHQ 5y ago
I used to use yarn all the time until I tried pnpm. The speed is amazing, and as a traveler I love that it works offline by default. I’d be curious to see some benchmarks between pnpm and yarn 3, because pnpm has been the fastest of the bunch for me. It also gets bonus points for pnpx, workspaces, and essentially being a drop-in replacement for npm.
- andrew_ 5y ago
  Please, if you're downvoting this, share why. The replies here are full of valid anecdotal evidence for every package manager being mentioned, and they're all valid. If you feel this is invalid or poor content to be sharing, please state why so conversation can be had.
- renke1 5y ago
  pnpm is really good. The workspace implementation is the only one that feels (mostly) intuitive and also comes with certain functionality usually associated with tools like Lerna. It also doesn't seem to break certain expectations that packages make in regard to node_modules and the like. While there a few things that could be improved, I think it's definitely worth a try and provides a good compromise between NPM and Yarn 2+.
  - chrisweekly 5y ago
    AND it is the only one of the three with a well-thought-out approach to node_modules^1 1. https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the-only-way https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the...
- null_deref 5y ago
  Does pnpm supports the behavior of > yarn install --offline ? A quick and lazy google search didn't yield a result...
- arcatek 5y ago
  We maintain a set of automated benchmarks against Yarn 1/2+ (PnP and node_modules tracked separately), pnpm, and npm: https://yarnpkg.com/benchmarks https://yarnpkg.com/benchmarks The fastest are usually either Yarn PnP or pnpm. Note however that regardless of the package managers it's quite clear that performances are reaching a plateau in the common cases. I personally believe a better thing to consider are feature set, stability, documentation, and general codebase health (since it impacts how fast features and bugfixes ship, and how dangerous upgrades may be). But those are quite a bit harder to measure, of course!
rudian 5y ago
Yarn was great and all, but it’s not npm so you have to convince the whole team to use it. I can’t believe npm still sucks after 10 years. Week doesn’t go by I have to nuke node_modules and occasionally the lock as well. It’s junk as far as I’m concerned, but I just happen to know what the problem is every time.
- eh9 5y ago
  Has it been a hard sell in your experience?
  - xzel 5y ago
    I don’t think in general I’ve ever had a hard time selling it. The issue is the decision pretty much all or nothing; everyone has to be using it as well. Getting a number of people to switch is always difficult.
    - gavinray 5y ago
      I've had repos where coworkers refused to use yarn, and would commit NPM's lock file Locally I just delete it and use yarn for all my commands, and they can use NPM for their commands. It doesn't make much of a difference, not actually sure what the problem is. Nobody would even know whether you're using yarn or NPM if you don't commit a lockfile I suppose
      - arcatek 5y ago
        Note that we don't recommend using both Yarn and npm: both have different feature sets, heuristics, and implementation details, and as a result your colleagues and you may have slightly different behaviors in development (on top of desync'd dependency trees). Just like no one would think of letting their developers choose whether they want to bundle their code using either Webpack or Rollup, the package manager should really be enforced at the project level, whether you choose Yarn or npm.
        5y ago
serverholic 5y ago
Any news on react-native support?
- arcatek 5y ago
  We support it once you enable the `node-modules` linker (cf our documentation). It's a little slower and doesn't leverage some of the stability improvements brought by PnP (in short, you get a good old node_modules folder without much fanciness), but you still get to benefit from all the other features and bugfixes we made since the 1.x.
dbjorge 5y ago
My team is still using yarn v1 because we want both dependabot support (rules out yarn v2+ and pnpm) and support for overriding transitive dependency versions to force security fixes (eg, yarn resolutions). We would love to explore other options but right now yarn v1 seems to be the only game in town that meets those requirements. Once npm implements their recently-accepted overrides RFC, we're eager to try switching to that.
mixedCase 5y ago
Does the combination of Yarn, VSCode and TypeScript work now? I've wasted time twice now trying to move projects to Yarn 2 just to have the tsserver LSP break every time, being unable to find the packages despite following the documentation to the letter.
- djxfade 5y ago
  I have never experiences any problems with that setup
- arcatek 5y ago
  We use Yarn / VSCode / TypeScript (both to maintain Yarn and at work), so we are very invested in this use case. If something didn't work, we'd notice it quickly and the fix wouldn't take long!
  - mixedCase 5y ago
    Well I just tried to make a repro by grabbing a random repo I had, but I get "Invalid authentication (as an anonymous user)" when trying to get a package from a GitHub registry, after configuring my scope with `yarn config set npmScopes.MYSCOPE.npmRegistryServer "https://npm.pkg.github.com https://npm.pkg.github.com"` and successfully logging in with `yarn npm login --scope MYSCOPE`. Every single time I've tried Yarn 2 I end up frustrated.
    - arcatek 5y ago
      We don't do support on HN, but if you really don't find information in our repository issues I'm sure our Discord can help. We publish all the Yarn packages to both the npm and GitHub package registries, so I'm certain it works fine.
- JazzXP 5y ago
  This is exactly what turned me off Yarn 2. I think it was a language server issue, but if it's broken, it's broken. It sent me back to NPM, and I rarely use Yarn these days at all.
neals 5y ago
So did the dawn of Yarn make package management for nodeJS better for everyone or do we now just have another packagemanger to choose from and take into account when we publish packages?
- 1123581321 5y ago
  Take a look at many of the other comments. My view as a regular user of JS tooling is that yarn provided a better option and also forced npm to become better in a hurry. The current level of package management fragmentation seems good for everyone.
- plorkyeran 5y ago
  Yarn forced NPM to get a lot better, so I'd consider it a significant net positive even for projects which don't use it.
jbverschoor 5y ago
So npm7 still copies everything in the local node_modules directory? Still sucks then.
- InsaneOstrich 5y ago
  Yeah, I was hoping that they would learn from Yarn pnp
  - jbverschoor 5y ago
    Ah.. they’re stubborn dev that don’t care about anything but themselves… These problems have been solved many times before. Not invented here
dzonga 5y ago
for me yarn 2 was a clusterfuck. I thought dependency resolution, would be better but nah. then it also polluted my workspace with dozens of json files. and issue of packages not being found, when using esm via node.
ggregoire 5y ago
What are the main benefits of v3 compared to v1? Is there any migration work needed to use v3 on a project bootstrapped with v1 or is it transparent?
ojkelly 5y ago
One of the reasons I really like Yarn 3, is the really good support for linking local dependencies. The whole “@internal/mypackage”: “workspace:*”. That, and the plugin system. Because it meant I could build on top of yarn a build/test system much like Bazel, Buck and Pants. But without the overhead of those tools. Honestly, being able to build functionality into tooling like this is really awesome. Especially when it’s aware dependency graph. I often have polyglot repos, with a heap of typescript, and some golang, and other stuff. I spent a couple of weeks last year hacking away on a plugin, that can look at the whole dependency tree defined in yarn - and develop a build graph that can build everything in the required order, taking advantage of every cpu thread available. While keeping track of what’s previously been built. From that, I extended the support to testing to do the same thing. I wrapped it all up into a nice package and published it to: https://yarn.build https://yarn.build Can be installed with this command yarn plugin import https://yarn.build/latest Then it’s just `yarn build` which runs `package.json#scripts.build`, and `yarn test` which runs `package.json#scripts.test`. — Since then, there’s been plenty of development. I added a bundle command. You tell it which local package to bundle up, and it copies your repo to a temporary folder, removes everything that package doesn’t need (useful in a giant monorepo), leaves the other packages it depends on. Finally it adds a file `entrypoint.js` which sets up pnp for you, and re-exports the `main` file from your target package. Then it zips it up for you ready for AWS Lambda (my use case), but also Docker and any other node runtime. And recently I hacked another interesting plugin that yarn and pnp enabled. A really neat plugin that lets you write package.yaml instead of package.json. If you replace package.json with package.yaml (or .yml), it will appear to yarn as a normal package.json. Everything works fine (with yarn, unsure about some node tooling), and you even get comments. It’s a completely separate plugin (because it’s pretty out there), and it only has an effect if you don’t have a package.json in your package folder. I’m using it on the golang packages in monorepo’s, because those developers are often a bit upset by seeing build tooling in a json file. The package.yaml plugin can be installed with the following command: yarn plugin import https://yarn.build/yaml It’s still a bit experimental, but works pretty well. — It’s all open source on GitHub, if you have any issues using it feel free to post a bug report. https://github.com/ojkelly/yarn.build https://github.com/ojkelly/yarn.build
akmittal 5y ago
Is yarn 3 stable, I dont see it published to npmjs.com. I dont even see yarn 2 stable

Yarn 3.0

154 points by Jowsey 5y ago

oefrha 5y ago

Anyone has seen stats on yarn 2 uptake? I’m still on yarn 1 and I know I’m far from the only one.

mrRandomGuy 5y ago
I tried updating my teams frontend pipelines from Yarn 1 to Yarn 2 since there seemed to be some significant performance improvements. I spent some time trying to understand why I needed a third party plugin to run the equivalent of `yarn install --production` I just said fuck it and I'll let the frontend team figure this shit out. So yeah, I wouldn't be surprised if the Yarn 1 usage is significantly higher than Yarn 2
jitl 5y ago
The only project of mine where I use Yarn 2 was one where arcanist, the yarn2 maintainer, added it himself. Otherwise, I use yarn@1 which requires significantly less brain cells than following yarn2 opinions/changes/plugins/installing
ninjaoxygen 5y ago
We also remained on Yarn 1 because developing packages using the workspaces feature is really nice. We did make an attempt at moving to Yarn 2, it did not work out well. At that time (probably 12 months ago or more) lots of upstream packages had broken package.json files, we never managed to fix them all. Lots of things with React were a bit screwy too!
theshrike79 5y ago
Still on Yarn 1. Looked at Yarn 2, saw that it was a ton of work (compared to our npm -> yarn 1 transition) and said sod it. Let's see if Yarn 1 -> 3 is any easier.
gregors 5y ago
Still on Yarn 1 with no plans on upgrading anytime soon.

nicoburns 5y ago

I'd be interested to know what HN's experience with Yarn 2 has been. Yarn 1 was compatible with NPM, so switching was easy, but Yarn 2 seems to need explicit support in a lot of cases. Had anyone found significant benefits from switching to yarn 2? And conversely, has anyone had any issues with this? EDIT: It seems that there is also a 3rd option: pnpm. Experiences with pnpm would also be welcomed.

crubier 5y ago
We have a monorepo with 200packages. NPM install times were longer than 1hour. Unusable. Yarn v2 took this down to 20 seconds. Yes, around 200x faster. They just are not comparable on that aspect. The issues we had are with some packages who don’t list their peerDependencies correctly, or which assume the file structure of node_modules will be the one made by npm. But yarn has improved and these obstacles are much easier now.
- dmitryminkovsky 5y ago
  That is so appealing... I don't have a monorepo with 200 packages but I do `yarn install` in a Dockerfile and if something changed that uncached that line, the whole thing can take 10 minutes or more to download, unpack, install. Would love to try Yarn 2 (3, now, I guess) when I can. Does Rome use yarn? Anyone using Rome in production?
  - city41 5y ago
    I haven't actually used Rome, but their installation guide mentions both yarn and npx, so that possibly means Rome is agnostic on them https://rome.tools/#installation-and-usage https://rome.tools/#installation-and-usage
  - tuxie_ 5y ago
    If you are on mac, this is a known docker issue because in non-Linux systems fs access is virtualized (docker runs on an Ubuntu running on a vm). Becomes pretty unusable.

bassman9000 5y ago

> Breaking Changes > Node 10 isn't supported anymore. 10 is LTS

akmittal 5y ago
Not really, it was supported till April, 21 https://github.com/nodejs/Release https://github.com/nodejs/Release
staticassertion 5y ago
Is there somewhere that actually talks about LTS releases? I'm trying to find when it's EOL and I'm getting mixed information - one page said it was April 2021, you're saying it's still LTS?
- nicoburns 5y ago
  https://nodejs.org/en/about/releases/ https://nodejs.org/en/about/releases/
  - staticassertion 5y ago
    Thanks, I don't use nodejs much so I tried Google'ing around and got tons of garbage results.
- shaicoleman 5y ago
  There's also the handy endoflife.date website https://endoflife.date/nodejs https://endoflife.date/nodejs
kyrra 5y ago
https://nodejs.org/ru/blog/release/v10.13.0/ https://nodejs.org/ru/blog/release/v10.13.0/ > This release marks the transition of Node.js 10.x into Long Term Support (LTS) with the codename 'Dubnium'. The 10.x release line now moves in to "Active LTS" and will remain so until April 2020. After that time it will move in to "Maintenance" until end of life in April 2021. Node 10 is past EoL at this point. 12 and 14 are the current LTS releases: https://nodejs.org/en/about/releases/ https://nodejs.org/en/about/releases/

ChicagoDave 5y ago

Why is is still master and not trunk?

bovermyer 5y ago
"trunk" is a relic of the bad old days and reminds me of Subversion. That naming convention needs to stay dead.
- ChicagoDave 5y ago
  I meant "main": Github: "Starting next month, all new source code repositories created on GitHub will be named "main" instead of "master" as part of the company's effort to remove unnecessary references to slavery and replace them with more inclusive terms. Teams need tools to help them collaborate and stay productive while remotely working."
  - InGoodFaith 5y ago
    > all new source code repositories keyword there being "new"
  - bovermyer 5y ago
    Fair enough. The "main vs master" argument has been done quite a lot lately, and I'm not going to weigh in on it here. But it seems a little... tangential... to argue about branch naming in this context, doesn't it?
    - ChicagoDave 5y ago
      Honestly my dry sense of humor took a swing and missed. Bigly.
deleted 5y ago
[deleted]
ComputerGuru 5y ago
Can you go bike shed somewhere else?

paxys 5y ago

Still can't believe they messed up Yarn so bad with v2. It was all set to replace npm, and now isn't anywhere in the picture.

moretti 5y ago
yarn 2 solved real problems with zero install and advanced PnP. Maybe the only problem was that it was released too early, wasn't mature enough when it came out. Now it's just better than v1 and npm, works particularly well on large mono repos where upgrading a package can often break other modules due to how node_modules hoisting works.
- rudian 5y ago
  The problem with Yarn 2 is that it wasn’t Yarn. You can’t change the whole thing and keep the same name. They thought people would just keep using Yarn out of inertia. That’s not how it works.
  - mbStavola 5y ago
    That's what the "V2" signifies: a major, (potentially) breaking change. I'm not surprised nor upset that V2 is radically different. It's all in the versioning scheme!
    - buu700 5y ago
      Eh. They're allowed to do that as per a literal definition of semver, but they turned it into a completely different tool with completely different usage patterns and use cases. It's one thing to have to make some small tweaks to handle an isolated breaking change in a dependency. It's another matter entirely to have a perfectly good core part of your stack deprecated out of the blue and told that you need to rewrite every line of code that it touches. I see this as analogous to the Angular 2 situation, except that Google actually did a good job maintaining Angular 1 (retroactively named "Angular.js") for a number of years afterwards and providing a solid migration path. Everyone who had staked their projects and businesses on the future of Angular 1 was understandably annoyed. All that being said, while I have problems with specifics of their approach, I actually think Yarn made the right call on this. After NPM caught up with v7, it became a bit of a wasted effort to have two redundant projects that were almost drop-in replacements for one another. Yarn staking out a different path at least justifies its continued existence. What I think could have been better is if they'd put an explicit acknowledgement in the migration docs that Yarn 2 wasn't going to be a good fit for all users of Yarn 1, and a recommendation of NPM 7 as an alternative successor to Yarn 1 for such users. An even nicer gesture would have been if they'd written an alternate migration doc for Yarn 1 -> NPM 7.

smashah 5y ago

Wasn't able to get over some of the decisions made on yarn 2. Hopefully yarn 3 is more compatible to a usual npm flow.

xtracto 5y ago

What are the advantages of using Yarn over NPM? It just feels to me that npm does anything that is needed and is available in stuff like ansible-node docker containers. Why should someone who is used to Yarn check Yarn?

madjam002 5y ago
For large repos it can be hundreds of times faster than NPM at installs
Kuinox 5y ago
We are forced to migrate from npm to yarn: - Somehow one of our dependencies fail to install with old version of npm. - Updating npm to last version fixes this, but on some machines, npm install fails with a 401 error despite having no private registries configured. Still no fixes for this bug after multiples months: - https://github.com/npm/cli/issues/2799 https://github.com/npm/cli/issues/2799 - https://github.com/npm/cli/issues/3284 https://github.com/npm/cli/issues/3284 - There is a lot of other issues on this. Before this, whe had multiples other issues with npm (thats may be still live): - npm is not extensible enough and require a lot of workarounds to be used in safely CI. - There are bugs thats are not fixed for 2 years that make npm ci not working. (https://github.com/npm/cli/issues/289 https://github.com/npm/cli/issues/289) - All bug reports have been closed after a new version release because they have no idea if they fixed a bug or not.

wdb 5y ago

I seem to have issues with using Yarn or NPM v7 with Gitlab NPM private registry. Sadly, I can't use NPM v7 or Yarn yet :(

john_cogs 5y ago
GitLab team member here. Can you share a bit more about the issues you are having? Would be happy to try to help resolve or open an issue if its a bug.
- wdb 5y ago
  Looks like it scheduled for 14.2 (https://gitlab.com/gitlab-org/gitlab/-/issues/330929 https://gitlab.com/gitlab-org/gitlab/-/issues/330929). I hope the `needs` ticket makes it into this release too Keeping my fingers crossed it mades it!

xcambar 5y ago

The single decision from the Yarn team to not offer a reasonable transition path from v1 to v2 was a total blocker for my teams. After trying it on seldected projects, we collectively decided that it was not worth it to follow a project that did not take its users' time seriously, since the migration was so hard. So, yarn@v1 then npm@v7+ for us.

ironmagma 5y ago
From the looks of it, the Yarn "team" is mostly one guy. Edit: I retract my previous comment, the additions/deletions count seems misleading. [1] https://github.com/yarnpkg/berry/graphs/contributors https://github.com/yarnpkg/berry/graphs/contributors
- arcatek 5y ago
  I was the main developer back when the 2.0 was started (so, like, rc.1), but since then we grew and are now a team, with at least four very active contributors of similar expertise. I believe this is the greatest accomplishment of the v2.
chadlavi 5y ago
Yep. At least give us some utilities to convert the config files. I'm not hand re-writing all that.

Lammy 5y ago

Don't forget to disable the tracking if you care about that sort of thing: https://yarnpkg.com/advanced/telemetry https://yarnpkg.com/advanced/telemetry `yarn config set enableTelemetry 0` per-project. `yarn config set --home enableTelemetry 0` per-user.

joshxyz 5y ago
damn this is not opt-in? lol

tdhz77 5y ago

Yarn had its place. It’s time to move on with npm. The newer version is so much faster and you won’t run into permissions issues like with yarn.

andrew_ 5y ago
Forced peerDependency installations in v7 are a deal breaker for me. And as a package author, it's one of the more painful changes to NPM in recent times. Lest we forget the debacle the between prepare, install, prePublish and prePublishOnly that we're still dealing with, and which the other package managers have to contend with.

dstaley 5y ago

One of the biggest things holding me back from transitioning my open source projects over to Yarn and PnP is Dependabot support. I'd even settle for support with the `node-modules` plugin at this point, but GitHub is of the opinion that there isn't much community usage of yarn v2 to warrant the additional development required to support yarn v2+. I'm really glad for all the forward thinking projects like yarn and pnpm are bringing to the node package management space, and I'm also glad to see that npm is listening and taking those advancements into consideration. I'm currently exploring using npm v7's workspaces feature, which was something I originally wanted to use yarn for.

dmitriid 5y ago

So... What exactly is this version, how is it different from yarn 2 that it warrants a major version update (not that I even know what yarn 2 was about), and how does it compare to npm?

andrew_ 5y ago

For my money, I'll take PNPM any day of the week. YMMV it's still faster than any version of Yarn or NPM hands down. https://pnpm.io/ https://pnpm.io/

FractalHQ 5y ago

I used to use yarn all the time until I tried pnpm. The speed is amazing, and as a traveler I love that it works offline by default. I’d be curious to see some benchmarks between pnpm and yarn 3, because pnpm has been the fastest of the bunch for me. It also gets bonus points for pnpx, workspaces, and essentially being a drop-in replacement for npm.

andrew_ 5y ago
Please, if you're downvoting this, share why. The replies here are full of valid anecdotal evidence for every package manager being mentioned, and they're all valid. If you feel this is invalid or poor content to be sharing, please state why so conversation can be had.
renke1 5y ago
pnpm is really good. The workspace implementation is the only one that feels (mostly) intuitive and also comes with certain functionality usually associated with tools like Lerna. It also doesn't seem to break certain expectations that packages make in regard to node_modules and the like. While there a few things that could be improved, I think it's definitely worth a try and provides a good compromise between NPM and Yarn 2+.
- chrisweekly 5y ago
  AND it is the only one of the three with a well-thought-out approach to node_modules^1 1. https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the-only-way https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the...
null_deref 5y ago
Does pnpm supports the behavior of > yarn install --offline ? A quick and lazy google search didn't yield a result...
arcatek 5y ago
We maintain a set of automated benchmarks against Yarn 1/2+ (PnP and node_modules tracked separately), pnpm, and npm: https://yarnpkg.com/benchmarks https://yarnpkg.com/benchmarks The fastest are usually either Yarn PnP or pnpm. Note however that regardless of the package managers it's quite clear that performances are reaching a plateau in the common cases. I personally believe a better thing to consider are feature set, stability, documentation, and general codebase health (since it impacts how fast features and bugfixes ship, and how dangerous upgrades may be). But those are quite a bit harder to measure, of course!

rudian 5y ago

Yarn was great and all, but it’s not npm so you have to convince the whole team to use it. I can’t believe npm still sucks after 10 years. Week doesn’t go by I have to nuke node_modules and occasionally the lock as well. It’s junk as far as I’m concerned, but I just happen to know what the problem is every time.

eh9 5y ago
Has it been a hard sell in your experience?
- xzel 5y ago
  I don’t think in general I’ve ever had a hard time selling it. The issue is the decision pretty much all or nothing; everyone has to be using it as well. Getting a number of people to switch is always difficult.
  - gavinray 5y ago
    I've had repos where coworkers refused to use yarn, and would commit NPM's lock file Locally I just delete it and use yarn for all my commands, and they can use NPM for their commands. It doesn't make much of a difference, not actually sure what the problem is. Nobody would even know whether you're using yarn or NPM if you don't commit a lockfile I suppose
    - arcatek 5y ago
      Note that we don't recommend using both Yarn and npm: both have different feature sets, heuristics, and implementation details, and as a result your colleagues and you may have slightly different behaviors in development (on top of desync'd dependency trees). Just like no one would think of letting their developers choose whether they want to bundle their code using either Webpack or Rollup, the package manager should really be enforced at the project level, whether you choose Yarn or npm.
      - 5y ago

serverholic 5y ago

Any news on react-native support?

arcatek 5y ago
We support it once you enable the `node-modules` linker (cf our documentation). It's a little slower and doesn't leverage some of the stability improvements brought by PnP (in short, you get a good old node_modules folder without much fanciness), but you still get to benefit from all the other features and bugfixes we made since the 1.x.

dbjorge 5y ago

My team is still using yarn v1 because we want both dependabot support (rules out yarn v2+ and pnpm) and support for overriding transitive dependency versions to force security fixes (eg, yarn resolutions). We would love to explore other options but right now yarn v1 seems to be the only game in town that meets those requirements. Once npm implements their recently-accepted overrides RFC, we're eager to try switching to that.

mixedCase 5y ago

Does the combination of Yarn, VSCode and TypeScript work now? I've wasted time twice now trying to move projects to Yarn 2 just to have the tsserver LSP break every time, being unable to find the packages despite following the documentation to the letter.

djxfade 5y ago
I have never experiences any problems with that setup
arcatek 5y ago
We use Yarn / VSCode / TypeScript (both to maintain Yarn and at work), so we are very invested in this use case. If something didn't work, we'd notice it quickly and the fix wouldn't take long!
- mixedCase 5y ago
  Well I just tried to make a repro by grabbing a random repo I had, but I get "Invalid authentication (as an anonymous user)" when trying to get a package from a GitHub registry, after configuring my scope with `yarn config set npmScopes.MYSCOPE.npmRegistryServer "https://npm.pkg.github.com https://npm.pkg.github.com"` and successfully logging in with `yarn npm login --scope MYSCOPE`. Every single time I've tried Yarn 2 I end up frustrated.
  - arcatek 5y ago
    We don't do support on HN, but if you really don't find information in our repository issues I'm sure our Discord can help. We publish all the Yarn packages to both the npm and GitHub package registries, so I'm certain it works fine.
JazzXP 5y ago
This is exactly what turned me off Yarn 2. I think it was a language server issue, but if it's broken, it's broken. It sent me back to NPM, and I rarely use Yarn these days at all.

neals 5y ago

So did the dawn of Yarn make package management for nodeJS better for everyone or do we now just have another packagemanger to choose from and take into account when we publish packages?

1123581321 5y ago
Take a look at many of the other comments. My view as a regular user of JS tooling is that yarn provided a better option and also forced npm to become better in a hurry. The current level of package management fragmentation seems good for everyone.
plorkyeran 5y ago
Yarn forced NPM to get a lot better, so I'd consider it a significant net positive even for projects which don't use it.

jbverschoor 5y ago

So npm7 still copies everything in the local node_modules directory? Still sucks then.

InsaneOstrich 5y ago
Yeah, I was hoping that they would learn from Yarn pnp
- jbverschoor 5y ago
  Ah.. they’re stubborn dev that don’t care about anything but themselves… These problems have been solved many times before. Not invented here

dzonga 5y ago

for me yarn 2 was a clusterfuck. I thought dependency resolution, would be better but nah. then it also polluted my workspace with dozens of json files. and issue of packages not being found, when using esm via node.

ggregoire 5y ago

What are the main benefits of v3 compared to v1? Is there any migration work needed to use v3 on a project bootstrapped with v1 or is it transparent?

ojkelly 5y ago

One of the reasons I really like Yarn 3, is the really good support for linking local dependencies. The whole “@internal/mypackage”: “workspace:*”. That, and the plugin system. Because it meant I could build on top of yarn a build/test system much like Bazel, Buck and Pants. But without the overhead of those tools. Honestly, being able to build functionality into tooling like this is really awesome. Especially when it’s aware dependency graph. I often have polyglot repos, with a heap of typescript, and some golang, and other stuff. I spent a couple of weeks last year hacking away on a plugin, that can look at the whole dependency tree defined in yarn - and develop a build graph that can build everything in the required order, taking advantage of every cpu thread available. While keeping track of what’s previously been built. From that, I extended the support to testing to do the same thing. I wrapped it all up into a nice package and published it to: https://yarn.build https://yarn.build Can be installed with this command yarn plugin import https://yarn.build/latest Then it’s just `yarn build` which runs `package.json#scripts.build`, and `yarn test` which runs `package.json#scripts.test`. — Since then, there’s been plenty of development. I added a bundle command. You tell it which local package to bundle up, and it copies your repo to a temporary folder, removes everything that package doesn’t need (useful in a giant monorepo), leaves the other packages it depends on. Finally it adds a file `entrypoint.js` which sets up pnp for you, and re-exports the `main` file from your target package. Then it zips it up for you ready for AWS Lambda (my use case), but also Docker and any other node runtime. And recently I hacked another interesting plugin that yarn and pnp enabled. A really neat plugin that lets you write package.yaml instead of package.json. If you replace package.json with package.yaml (or .yml), it will appear to yarn as a normal package.json. Everything works fine (with yarn, unsure about some node tooling), and you even get comments. It’s a completely separate plugin (because it’s pretty out there), and it only has an effect if you don’t have a package.json in your package folder. I’m using it on the golang packages in monorepo’s, because those developers are often a bit upset by seeing build tooling in a json file. The package.yaml plugin can be installed with the following command: yarn plugin import https://yarn.build/yaml It’s still a bit experimental, but works pretty well. — It’s all open source on GitHub, if you have any issues using it feel free to post a bug report. https://github.com/ojkelly/yarn.build https://github.com/ojkelly/yarn.build

akmittal 5y ago

Is yarn 3 stable, I dont see it published to npmjs.com. I dont even see yarn 2 stable