The pnpm init command is the entry point for every new project, but its behavior has evolved significantly in pnpm 10. The default module system is now ESM (“type”: “module”), a –bare flag strips the manifest down to only required fields, and version pinning is handled through the devEngines.packageManager field rather than the older packageManager…
Every Yarn project begins with a single file. Before dependencies are installed, before scripts are run, and before lockfiles are generated, there is package.json. This file is the manifest—the contract between your project, the package manager, and anyone who clones the repository. Running yarn init is the first command in any new project, and understanding…
Bun’s package manager is defined by its lockfile strategy. For its first two years, Bun used a binary lockfile named bun.lockb, which was faster to parse but opaque to review, Git diffs, and merge tools. In December 2024, Bun introduced a text-based alternative (bun.lock), and since Bun v1.2, it has become the default. This chapter…
The package.json file is the single most important file in a Node.js project. It is the manifest that tells npm what the project is, what it depends on, and how to run it. Every npm install, npm run, and npm publish reads this file. The npm documentation describes it as “the whole interface” to npm—without…
The previous chapter established that pnpm stores packages once and links them into your project. This chapter explains the mechanism: the .pnpm virtual store and the two types of links that connect it to the rest of the filesystem. An understanding of this architecture is not academic. It explains why pnpm installs are fast, why…
Every dependency you add, upgrade, or remove triggers a two-file update: package.json records the intent (a version range like ^4.18.0), and yarn.lock records the reality (the exact version and integrity hash that was resolved). The manifest is what you write; the lockfile is what Yarn writes. Understanding this division is the difference between a project…
Package management in Bun follows the familiar add, remove, and update pattern, but the execution engine underneath is fundamentally different. Because Bun is a native binary with a global install cache and a highly optimized resolver, the same commands that take seconds in npm or minutes in Yarn complete in milliseconds. This chapter covers the…
Every package you install with npm lands in one of two places in your package.json: dependencies or devDependencies. The distinction is not cosmetic. It determines whether the package is installed when you build for production, whether it is shipped in your deployment artifact, and whether your production server can actually run the code after deployment….
The daily rhythm of package management is a three-command cycle: add what you need, update what has changed, and remove what is no longer used. pnpm’s commands for these operations follow a consistent pattern: they modify package.json, resolve the change into pnpm-lock.yaml, and update the virtual store and symlinks in node_modules. The critical difference from…
Package management is the daily rhythm of working with Yarn. You add a library to solve a problem, upgrade it when a bug is fixed or a feature lands, and remove it when the dependency is no longer needed. Each of these operations modifies two files—package.json and yarn.lock—and the commands that perform them differ significantly…