8 ms·

With the addition of workspaces and yarn.lock support to npm 7, are there still reasons to use yarn over npm?

by kjaer 6y ago

BillinghamJ 6y ago
And interestingly, Yarn 2 actually goes quite a long way off what a lot of Node users wanted from it originally (at least we have no interest in moving to it). If you just use "yarn" as you'd think of it, you are probably still using Yarn 1, so I guess it's being thought of as a different parallel project
imedadel 6y ago
From https://blog.npmjs.org/post/621733939456933888/npm-v7-series-why-keep-package-lockjson https://blog.npmjs.org/post/621733939456933888/npm-v7-series... > The package-lock.json file is not only useful for ensuring deterministically reproducible builds. We also lean on it to track and store package metadata, saving considerably on package.json reads and requests to the registry. Since the yarn.lock file is so limited, it doesn’t have the metadata that we need to load on a regular basis. So I guess there are some performance benefits with npm 7 compared to Yarn 1?
- wayneftw 6y ago
  Yarn v1 does caching - https://classic.yarnpkg.com/en/docs/cli/cache/ https://classic.yarnpkg.com/en/docs/cli/cache/
patwolf 6y ago
I was happy when yarn first came onto the scene and gave npm the kick in the butt it needed to improve. Now I wish yarn could be deprecated and we could go back to a single package manager. There's unfortunately segmentation in different areas around package managers, e.g. electron seems to prefer yarn. And for package maintainers there's extra overhead to document and test installation with both npm and yarn.
- chrisweekly 6y ago
  I hear you, but things are not really moving in that direction, because it's not that simple. The closer you look into what they do and how, the clearer it becomes that [npm7 vs yarn1 vs yarn2 vs pnpm] is the current set of legit choices, for various reasons.
arxpoetica 6y ago
No. Use pnpm (and Volta js) instead.
- keb_ 6y ago
  I've been considering switching to pnpm for political reasons since using open source projects that are ultimately at the mercy of big corps (npm > Microsoft, yarn > Facebook) makes me slightly uneasy. But I'm hesitant to because pnpm seems so new. Have you encountered any regularly occurring issues or headaches regarding pnpm?
  - dstaley 6y ago
    FWIW yarn v2 isn't affiliated with Facebook. The lead maintainer is a Datadog employee, but the project isn't at the mercy of any company.
    - keb_ 6y ago
      Thank you. I was not aware of this. Also, last I heard transitioning from yarn v1 to v2 was not straightforward. Do you know if this is still the case?
      - acemarke 6y ago
        FWIW, I recently tried a branch where I migrated our existing repo from Yarn v1 to v2. The immediate issues I ran into were lack of Yarn v2 support for some features critical for internal enterprise usage: no support for the `strictSsl` / `caFile` config options from NPM / Yarn v1, and an inability to read lockfile URLs that were pointing to an internal NexusRepository instance for proxying NPM package installation. Both issues were resolved very quickly by the Yarn team. I then ran into a problem where the post-install build steps could not run in a locked-down corporate security environment, and that issue was also addressed very quickly, with the Yarn team putting up a PR that tried different process launching approaches and iterating until one worked for me. Having sorted out those issues, I was able to move on to actually following the steps in the Yarn v2 migration guide [0]. The steps worked basically as advertised. The `@yarnpkg/doctor` tool identified several places where we were relying on imports that hadn't been strictly declared, so I fixed those. Starting up the app caused some thrown errors as other non-declared imports were hit, so I kept iterating on fixing those. I also used the `@yarnpkg/pnpify --vscode` option to generate some kind of settings file for VS Code, and added the suggested "zip file system" extension to VS Code. That allowed me to right-click a library TS type, "Go to Definition", and show a file that was still packed in a package tarball. I had to switch off to other tasks and haven't had time to go back and finish trying out the migration. But, parts of our codebase were running correctly, and it looked like I just needed to finish out the process of checking for any remaining non-declared dependencies. Can't vouch for how this would work out in production or a larger build setup, but things looked promising overall. [0] https://yarnpkg.com/advanced/migration https://yarnpkg.com/advanced/migration
crubier 6y ago
Yarn v2 PnP is simply a lifesaver if you have a medium+ sized monorepo. We have a monorepo with 180 packages here. Without pnp, it takes 1h+ just to npm install any new third party package in any local package, it’s a joke. With pnp it takes 18s. So yes, from my point of view NPM is completely inadequate for any serious JS codebase.
- georgyo 6y ago
  Cannot figure out why you are being down voted. YarnV1 and NPM are horrible if you have a large dependency tree. YarnV2 was the first time I enjoyed the package manager.
  - 411111111111111 6y ago
    Likely because he indirectly said that projects using less then 180 dependencies aren't serious.
    - romanoderoma 6y ago
      could it be that in some languages (like my language for example) serious is kinda of a synonym for large? I've been downvoted at times for using it to mean exactly that, but I can't help it after more than 40 years of thinking in a language different from English.
    - crubier 6y ago
      By serious I meant large indeed, I’m not a native speaker. I have some serious projects that have less than 180 packages too aha. But if you start an ambitious company with a JS codebase today, start with yarn v2, you’ll save yourself some pain in the future.
- benologist 6y ago
  This NPM cache been a huge time-saver for me, you can run it locally or across your whole network for a shared cache - https://guides.sonatype.com/repo3/quick-start-guides/proxying-maven-and-npm/ https://guides.sonatype.com/repo3/quick-start-guides/proxyin... https://hub.docker.com/r/sonatype/nexus/ https://hub.docker.com/r/sonatype/nexus/
Sheepsteak 6y ago
I've been trying the npm workspaces support in the last few beta and release candidate releases and it just wasn't stable enough for me. https://github.com/npm/cli/issues/1984 https://github.com/npm/cli/issues/1984
cwp 6y ago
Npm is very buggy for local dependencies - eg in a monorepo that contains node modules. That might be fixed in npm 7, but I doubt it. OTOH, yarn handles this just fine.
moogly 6y ago
Are there reasons to go back to npm? I switched back when yarn came out and haven't looked back. Been super happy with yarn. Can't say the same about npm.
- kjaer 6y ago
  People are more likely to already have npm installed and to be familiar with it. So there's an argument to be made that all else being equal, picking npm lowers the barrier to entry for new contributors. This consideration could be especially important for open source projects.
  - moogly 6y ago
    That's a valid point, but I don't think the barrier is particularly high. I've done the switch from npm to yarn once. It was a process measured in hours to understand the differences. It's not like Git vs Subversion or something like that.
- azangru 6y ago
  > Are there reasons to go back to npm? Ships with Node.
  - moogly 6y ago
    I don't think that's very compelling, versioning-wise (it's still independently versioned). Futhermore, the official node docker images come with yarn pre-installed, and there appears to be no way to bundle in a specific npm version in source control, like you can with `yarn policies set-version` (v1). That has worked wonders for us. Before yarn we used to have problems with developers using different versions of npm on their machines/build agents, and .nvmrc/"engines" doesn't help you there other than being an "error gate". The yarn executable acting like a shim delegating to the checked-in version is brilliant for versioning (especially CI).

With the addition of workspaces and yarn.lock support to npm 7, are there still reasons to use yarn over npm?

by kjaer 6y ago

With the addition of workspaces and yarn.lock support to npm 7, are there still reasons to use yarn over npm?

And interestingly, Yarn 2 actually goes quite a long way off what a lot of Node users wanted from it originally (at least we have no interest in moving to it). If you just use "yarn" as you'd think of it, you are probably still using Yarn 1, so I guess it's being thought of as a different parallel project

imedadel 6y ago

From https://blog.npmjs.org/post/621733939456933888/npm-v7-series-why-keep-package-lockjson https://blog.npmjs.org/post/621733939456933888/npm-v7-series... > The package-lock.json file is not only useful for ensuring deterministically reproducible builds. We also lean on it to track and store package metadata, saving considerably on package.json reads and requests to the registry. Since the yarn.lock file is so limited, it doesn’t have the metadata that we need to load on a regular basis. So I guess there are some performance benefits with npm 7 compared to Yarn 1?

wayneftw 6y ago
Yarn v1 does caching - https://classic.yarnpkg.com/en/docs/cli/cache/ https://classic.yarnpkg.com/en/docs/cli/cache/

patwolf 6y ago

I was happy when yarn first came onto the scene and gave npm the kick in the butt it needed to improve. Now I wish yarn could be deprecated and we could go back to a single package manager. There's unfortunately segmentation in different areas around package managers, e.g. electron seems to prefer yarn. And for package maintainers there's extra overhead to document and test installation with both npm and yarn.

chrisweekly 6y ago
I hear you, but things are not really moving in that direction, because it's not that simple. The closer you look into what they do and how, the clearer it becomes that [npm7 vs yarn1 vs yarn2 vs pnpm] is the current set of legit choices, for various reasons.

arxpoetica 6y ago

No. Use pnpm (and Volta js) instead.

keb_ 6y ago
I've been considering switching to pnpm for political reasons since using open source projects that are ultimately at the mercy of big corps (npm > Microsoft, yarn > Facebook) makes me slightly uneasy. But I'm hesitant to because pnpm seems so new. Have you encountered any regularly occurring issues or headaches regarding pnpm?
- dstaley 6y ago
  FWIW yarn v2 isn't affiliated with Facebook. The lead maintainer is a Datadog employee, but the project isn't at the mercy of any company.
  - keb_ 6y ago
    Thank you. I was not aware of this. Also, last I heard transitioning from yarn v1 to v2 was not straightforward. Do you know if this is still the case?
    - acemarke 6y ago
      FWIW, I recently tried a branch where I migrated our existing repo from Yarn v1 to v2. The immediate issues I ran into were lack of Yarn v2 support for some features critical for internal enterprise usage: no support for the `strictSsl` / `caFile` config options from NPM / Yarn v1, and an inability to read lockfile URLs that were pointing to an internal NexusRepository instance for proxying NPM package installation. Both issues were resolved very quickly by the Yarn team. I then ran into a problem where the post-install build steps could not run in a locked-down corporate security environment, and that issue was also addressed very quickly, with the Yarn team putting up a PR that tried different process launching approaches and iterating until one worked for me. Having sorted out those issues, I was able to move on to actually following the steps in the Yarn v2 migration guide [0]. The steps worked basically as advertised. The `@yarnpkg/doctor` tool identified several places where we were relying on imports that hadn't been strictly declared, so I fixed those. Starting up the app caused some thrown errors as other non-declared imports were hit, so I kept iterating on fixing those. I also used the `@yarnpkg/pnpify --vscode` option to generate some kind of settings file for VS Code, and added the suggested "zip file system" extension to VS Code. That allowed me to right-click a library TS type, "Go to Definition", and show a file that was still packed in a package tarball. I had to switch off to other tasks and haven't had time to go back and finish trying out the migration. But, parts of our codebase were running correctly, and it looked like I just needed to finish out the process of checking for any remaining non-declared dependencies. Can't vouch for how this would work out in production or a larger build setup, but things looked promising overall. [0] https://yarnpkg.com/advanced/migration https://yarnpkg.com/advanced/migration

crubier 6y ago

Yarn v2 PnP is simply a lifesaver if you have a medium+ sized monorepo. We have a monorepo with 180 packages here. Without pnp, it takes 1h+ just to npm install any new third party package in any local package, it’s a joke. With pnp it takes 18s. So yes, from my point of view NPM is completely inadequate for any serious JS codebase.

georgyo 6y ago
Cannot figure out why you are being down voted. YarnV1 and NPM are horrible if you have a large dependency tree. YarnV2 was the first time I enjoyed the package manager.
- 411111111111111 6y ago
  Likely because he indirectly said that projects using less then 180 dependencies aren't serious.
  - romanoderoma 6y ago
    could it be that in some languages (like my language for example) serious is kinda of a synonym for large? I've been downvoted at times for using it to mean exactly that, but I can't help it after more than 40 years of thinking in a language different from English.
  - crubier 6y ago
    By serious I meant large indeed, I’m not a native speaker. I have some serious projects that have less than 180 packages too aha. But if you start an ambitious company with a JS codebase today, start with yarn v2, you’ll save yourself some pain in the future.
benologist 6y ago
This NPM cache been a huge time-saver for me, you can run it locally or across your whole network for a shared cache - https://guides.sonatype.com/repo3/quick-start-guides/proxying-maven-and-npm/ https://guides.sonatype.com/repo3/quick-start-guides/proxyin... https://hub.docker.com/r/sonatype/nexus/ https://hub.docker.com/r/sonatype/nexus/

Sheepsteak 6y ago

I've been trying the npm workspaces support in the last few beta and release candidate releases and it just wasn't stable enough for me. https://github.com/npm/cli/issues/1984 https://github.com/npm/cli/issues/1984

cwp 6y ago

Npm is very buggy for local dependencies - eg in a monorepo that contains node modules. That might be fixed in npm 7, but I doubt it. OTOH, yarn handles this just fine.

moogly 6y ago

Are there reasons to go back to npm? I switched back when yarn came out and haven't looked back. Been super happy with yarn. Can't say the same about npm.

kjaer 6y ago
People are more likely to already have npm installed and to be familiar with it. So there's an argument to be made that all else being equal, picking npm lowers the barrier to entry for new contributors. This consideration could be especially important for open source projects.
- moogly 6y ago
  That's a valid point, but I don't think the barrier is particularly high. I've done the switch from npm to yarn once. It was a process measured in hours to understand the differences. It's not like Git vs Subversion or something like that.
azangru 6y ago
> Are there reasons to go back to npm? Ships with Node.
- moogly 6y ago
  I don't think that's very compelling, versioning-wise (it's still independently versioned). Futhermore, the official node docker images come with yarn pre-installed, and there appears to be no way to bundle in a specific npm version in source control, like you can with `yarn policies set-version` (v1). That has worked wonders for us. Before yarn we used to have problems with developers using different versions of npm on their machines/build agents, and .nvmrc/"engines" doesn't help you there other than being an "error gate". The yarn executable acting like a shim delegating to the checked-in version is brilliant for versioning (especially CI).