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…
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…
The conventional wisdom around pnpm installation has shifted significantly. Corepack, once the recommended path, is now considered outdated by the pnpm maintainers themselves, with the standalone script emerging as the preferred method. This chapter covers both approaches, the reasons for the shift, and the version-pinning mechanism that makes pnpm installations reproducible across machines and CI…
Every JavaScript package manager before pnpm solved the same problem in the same way: download packages, copy them into a node_modules folder, and repeat for every project. pnpm discards the copying entirely. It stores every file of every package exactly once on your disk in a global content-addressable store, then constructs a node_modules directory out…
Large CSV files are a nightmare to open. Excel crashes. Memory overflows. Your code times out before it can process a single row. I built a free tool that solves this. What it does: Use cases: Privacy:100% client-side. Nothing uploaded. Try it: tools.kandz.me/csv-file-splitter
1. Toolchain & Corepack 2. Project Initialization 3. Dependency Management 4. Installation & Lockfile 5. Running Scripts & Binaries 6. Workspaces (Monorepos) 7. Configuration (.yarnrc.yml) 8. Plug’n’Play (PnP) 9. Zero-Installs 10. Patching Dependencies 11. Publishing Packages 12. Cache & Registry Management 13. Environment Variables 14. CI/CD GitHub Actions (Standard) 15. npm to Yarn Migration
Migrating from npm to Yarn is not a single command. It is a sequence of decisions: which Yarn version to target, whether to use Plug’n’Play or node_modules, how to convert the lockfile, and how to reconfigure the settings that npm stored in .npmrc. The most common mistake is running yarn install on an npm project…
A CI pipeline that installs dependencies without immutable installs is a pipeline that lies. It resolves new versions silently, rewrites the lockfile if needed, and produces a build that may not match what developers tested locally. Yarn Berry changes this default: when it detects a CI environment, it automatically enables immutable installs. A lockfile that…
Publishing a package is the act of making it available for others to install. In Yarn Berry, the command is yarn npm publish. It packs the active workspace into a tarball and uploads it to a registry. The critical difference from Yarn Classic is the command name: Classic used yarn publish, Berry uses yarn npm…
A dependency has a bug. The upstream fix is months away, or the maintainer is unresponsive, or the fix exists only in a pull request that has not been merged. Forking the repository is heavy: you lose the link to the original, you must maintain the fork, and your package.json points to a Git URL…