Yarn 1.x is a hotfix line, and its lockfile is the only integrity record

The branch exists to make leaving it easier

The first thing the README says is that this repository holds the sources for Yarn 1.x, that the latest version at the time of writing was 1.22, and that new releases are tracked on the berry repository, at 3.2.3 at that point, with a next major in progress. The stated purpose of keeping the branch is historical reference plus the occasional hotfix published to ease the migration path.

Contributing is closed the same way. The 1.x codebase is described as fairly old and accepting security fixes only, with new features and bugfixes directed to berry. The README goes further than that and recommends migrating outright, on the grounds that the later releases have been maintained longer than 1.x.

The dates agree. The last push was on 2026-05-12 and the newest release is v1.22.22 from 2024-03-09, with v1.22.21 and v1.22.20 both published on 2023-11-14. So the branch still takes commits, but a commit is a hotfix, not development.

The manifest reads 1.23.0-0 and no 1.23 was ever tagged

The version skew inside the repository is easy to miss and worth knowing before you file an issue against the wrong tree. The root package.json declares:

  "name": "yarn",
  "installationMethod": "unknown",
  "version": "1.23.0-0",
  "license": "BSD-2-Clause",
  "preferGlobal": true

A 1.23.0-0 is a prerelease marker, and there is no 1.23 release in the tag list. The highest published version is 1.22.22. So the code on master is a 1.23 that never shipped, and a `yarn --version` on a machine installed from npm will not match the version string in this manifest.

The same file also resolves a licensing question the repository metadata leaves open. The project's license field does not identify a license, while the manifest declares BSD-2-Clause. Two different files, two different levels of certainty, and the manifest is the one npm reads.

nodeLinker is the switch that decides what lands on disk

The migration guidance does not ask you to change your habits so much as to pick a layout. The `nodeLinker` setting chooses between node_modules like npm, symlinks like pnpm, and manifest files via Yarn PnP. One setting, three different on-disk arrangements.

Each arrangement has a different way of failing, which is why the choice cannot be deferred. node_modules duplicates packages and works with any tool that assumes a filesystem tree. A symlink layout breaks anything that walks the tree expecting real directories, and on Windows it depends on whether the account is allowed to create links. PnP removes node_modules entirely and resolves from generated manifests, which is fast and small but requires every tool in the chain to understand the resolution model.

The 1.x branch has no `nodeLinker` setting of its own. That option lives in the current documentation, which is the first sign that this repository is not where the current behaviour is defined.

There is no install command here, and there are two documentation sites

The installation section contains no command. It sends you to the Installation Guide on the project website, and the usage section sends you to a Usage Guide on the same site. The 1.x homepage is a different address, classic.yarnpkg.com, from the yarnpkg.com pages the README links to.

That split is the trap for anyone new to the project. classic.yarnpkg.com documents the line whose sources live in this repository. The installation guide on yarnpkg.com documents the line tracked on berry, currently 3.2.3. An install command you copy from the current site gives you a Yarn that does not read the same settings, does not use the same lockfile semantics, and does not have a `nodeLinker` setting in 1.x at all.

The practical rule for a 1.x project is that the version has to be pinned explicitly, everywhere, because nothing in the documentation is going to stop a fresh install from landing on a different major.

Flat Mode trades npm's nesting for a single resolved version

One feature states a behavioural difference from npm outright. Flat Mode resolves mismatched versions of a dependency to a single version so the tree holds no duplicates. The contrast is the layout npm uses, which the nodeLinker description names as node_modules like npm, where a second copy of a conflicting package is nested under whichever package needed it.

So the two approaches resolve the same graph differently: yarn hoists one copy and discards the duplicates, npm keeps both and pays for it in disk and in modules loaded at startup. That is the whole argument for the flag, and it is a real argument for a project with a wide dependency tree.

The gap is that the documentation does not say which side of a version conflict gets the version it asked for. Two libraries pinned to incompatible majors of the same dependency is exactly the case where that matters, so run it before you trust the flag with a tree that has one.

The checksums live in yarn.lock, so a rewritten lockfile loses them

The security claim is specific: Yarn uses checksums to verify the integrity of every installed package before its code is executed. The dependency list carries `ssri` and `hash-for-dep` alongside the tar handling packages, which is the integrity machinery sitting under that sentence.

The consequence is where the data lives. Checksums are a property of the lockfile, not of the local cache, so the guarantee holds exactly as long as the yarn.lock in the repository keeps its integrity fields. A lockfile regenerated by a different tool, or hand-edited during a hurried dependency bump, comes back without the entries the check reads, and the check quietly has nothing to verify.

Two other guarantees sit in the same family. Offline Mode reuses packages already in the cache without a network connection, which makes air-gapped builds possible and makes a stale cache a silent source of old versions. Network Resilience means one failed request does not fail the install and requests are retried, so a flaky network slows an install instead of breaking it, and a partially resolved graph is retried rather than written.

Babel 6, Flow types and `request` date the tree you would patch

The build stack is the fastest way to date this codebase. The root has a .babelrc, .flowconfig and a flow-typed/ directory, and the manifest pins babel-runtime at ^6.26.0, babel-core at ^6.26.0 and babel-loader at ^6.2.5. Alongside them sit commander at ^2.9.0, chalk at ^2.1.0, inquirer at ^6.2.0, mkdirp at ^0.5.1 and request at ^2.87.0, which is a dependency line most projects moved off years ago.

There is a test story here too. __tests__/ and end_to_end_tests/ sit beside four separate CI configurations, CircleCI, AppVeyor, Azure Pipelines and a Jenkins groovy job, plus a Dockerfile.dev. Four CI systems for a frozen branch is what happens when a project spans years without consolidating.

If you need a patch in 1.x, you are patching this tree, and this tree's own toolchain is what has to build and test it. On a current Node, the first problem is the build, not your change.

The npm name was donated, which matters if you fork and publish

The repository's own license metadata resolves to nothing, and the manifest says BSD-2-Clause. Read the LICENSE file rather than the badge, and note that BSD-2-Clause is permissive enough for commercial use with a notice retained.

There is a second, smaller rights question in the credits. The npm package name `yarn` was donated by Sam Holmes, and the README thanks him for it. That is not a licence term, but it is the reason the name is not simply the project's to hand out, so a fork that publishes under the same package name is a different proposition from a fork that publishes under its own.

SECURITY.md sits at the root next to CODE_OF_CONDUCT.md and CONTRIBUTING.md. On a branch that accepts security fixes only, that file is the route to report a problem, and patching locally is the wrong first move.

Editorial conclusion

Adopt Yarn 1.x only if you are inheriting a repository that already has a yarn.lock and a 1.x-based CI image, because migrating is more work than staying and the migration guide is where the effort goes. Do not start a new project on 1.x, and do not read this branch as evidence of how Yarn works today, since the code here is kept for historical purposes. Verify three things: the exact 1.x version your lockfile and CI image expect, whether the yarn.lock in your repository still carries its integrity fields after any tooling has rewritten it, and which of the two documentation sites, classic.yarnpkg.com or yarnpkg.com, the instructions you are following actually describe.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes