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…
Every yarn install is a network request away from failure. The npm registry can go down, a corporate proxy can block a scoped package, or a build server can be air-gapped entirely. Yarn’s offline caching and mirroring features exist to eliminate that dependency: once packages are downloaded, they are stored locally and can be reused…
GitHub Pages turns a repository into a static website. It is not a general-purpose web host. It serves HTML, CSS, JavaScript, and assets directly from a branch or a GitHub Actions artifact, with no server-side execution, no database, and no dynamic request handling. For documentation, project landing pages, and personal blogs, it is free, integrated…
A tag is a Git concept: a fixed pointer to a specific commit that never moves. A release is a GitHub concept layered on top of a tag: a page with release notes and downloadable binary artifacts. Confusing the two is common. You can tag a commit without creating a release, but you cannot create…
GitHub Projects (v2) is not a board. It is a database with multiple views. This distinction is the single most important concept to internalize before touching the interface. The classic Projects product—columns of cards, one board per repository—is deprecated and being retired. The modern Projects product stores items as rows in a table, and the…
A repository is only as safe as the gates that guard its main branch. Branch protection rules are those gates: they define who can push, what must pass before a merge, and whether history can be rewritten. CODEOWNERS is the routing table that ensures the right people review the right files. Used together, they turn…