Yarn

Yarn is a command-line package manager for JavaScript that replaced npm’s early install pipeline with a deterministic, checksum-verified resolver and a global download cache. It reads a project’s package.json, resolves the full dependency graph against npm-compatible registries, and writes a detailed yarn.lock file so that the exact same dependency tree is reproduced on every machine and in CI, regardless of install order or timing.

This repository holds Yarn Classic (the 1.x line), which is now in maintenance mode — new development happens in the separate yarnpkg/berry repository (Yarn 2+, with Plug’n’Play and workspaces baked in from the start). Yarn 1.x still sees wide production use because of its stability, its offline cache, and its long-standing node_modules-based linking model that behaves like npm’s while installing markedly faster through parallelized, deduplicated fetches.

What You Get

• A deterministic yarn.lock lockfile format that pins exact resolved versions and checksums for every dependency in the tree
• A global, content-addressed offline cache so previously downloaded packages install again without a network connection
• Parallelized, request-queued fetching that installs dependencies faster than sequential resolution
• Checksum verification (ssri/ integrity hashes) of every fetched package before it’s unpacked and executed
• Built-in workspaces support for managing multiple packages in a single monorepo
• A full command surface — add, remove, upgrade, why, audit, licenses, outdated, link — covering day-to-day dependency workflows

Common Use Cases

• Installing and locking dependencies for a Node.js application so CI and every developer machine resolve identical versions
• Managing a JavaScript monorepo with Yarn workspaces, hoisting shared dependencies to a single top-level node_modules
• Running fully offline installs on CI runners or in air-gapped environments using Yarn’s local package cache
• Auditing installed dependencies for known vulnerabilities and license compliance before a release
• Debugging why a particular version of a transitive dependency was resolved, using yarn why

Under The Hood

Architecture Execution starts at bin/yarn.js, which loads the compiled CLI entry in src/cli/index.js; that module parses global flags with commander, resolves the project root by walking up for a package.json, loads .yarnrc config via rc.js, and dispatches to one of roughly forty command modules under src/cli/commands/ (install.js, add.js, upgrade.js, and so on). Each command drives a shared pipeline: package-request.js and package-resolver.js build the dependency graph by delegating to per-source resolvers in src/resolvers/ (npm registry, git, tarball, workspace, exotic protocols), package-fetcher.js hands off to matching fetchers in src/fetchers/ to download and checksum-verify each package, package-hoister.js computes a flattened node_modules layout, and package-linker.js performs the actual filesystem linking and install-script execution. A Config object threads through the whole pipeline carrying the registry clients, cache location, and reporter instance, keeping resolution, fetching, and linking as distinct, swappable layers rather than one monolithic install routine.

Tech Stack Yarn is a Node.js CLI (engines.node >= 4.0.0) written in Flow-typed ES2015+ JavaScript, transpiled with Babel (babel-preset-env/babel-preset-flow) and bundled for distribution via a Gulp/Webpack build (gulpfile.js, scripts/build-webpack.js). It talks to npm-compatible registries over HTTP using request, verifies integrity with ssri, parses/writes its lockfile with a hand-rolled parser plus js-yaml for config, and uses inquirer for interactive prompts (e.g. upgrade-interactive). CI runs across CircleCI, AppVeyor, and Azure Pipelines to cover Linux, macOS, and Windows.

Code Quality 159 of the 160 files under src/ carry @flow type annotations, giving the resolver/fetcher/linker pipeline real static typing rather than relying on JSDoc or runtime checks alone. The test suite under __tests__/ contains over 300 test files mirroring the src/ structure (commands/, resolvers/, registries/, util/) and runs on Jest with fixture-based integration tests for real install scenarios; yarn test also runs eslint and flow check before the Jest suite, backed by an .eslintrc.json with several custom eslint-plugin-yarn-internal rules. Errors are modeled as explicit typed classes (MessageError, ProcessTermError in errors.js) rather than plain thrown strings.

API Design As a CLI rather than an importable library, its “API” is its command surface and lockfile format: commands follow consistent verb-noun naming (add, remove, upgrade, why, licenses, audit) with shared flag conventions (--offline, --frozen-lockfile, --flat) applied uniformly across install-affecting commands, and the yarn.lock format is documented and stable enough that other tools parse it directly. Getting started requires no configuration beyond an existing package.json — yarn install with no arguments is the common entry point, though the project itself now directs new users toward its successor (yarnpkg/berry) rather than extending this 1.x surface further.