updating-dependencieslisted

# Updating dependencies Every upgrade is somebody else's code entering the project. It is ordinary work, but it is the kind where a green build is not the same as a safe change. ## One at a time, and separately - A security patch is its own change. A routine bump is its own change. A major version is its own change, and usually its own task. - Never mix a dependency update into a feature. When something breaks a week later, the first question is "what changed", and a diff that did two things cannot answer it. - Update the lockfile in the same commit as the manifest, always. A manifest and lockfile that disagree is a build that works for you and nobody else. ## Read before you upgrade Look at the changelog or release notes for every version you are crossing, not just the one you are landing on. - Breaking changes, deprecations, and anything about defaults changing. - For a major version, find the migration guide. If there is not one, that is information about the package. - Check the package is still maintained: when was the last release, are issues answered. If the update needs code changes, make them in the same change and say so in the message. ## Prove it still works The test suite passing is necessary and not sufficient. 1. Full suite, typecheck, lint — the repo's own commands. 2. Run the thing the dependency is actually used for. Tests often mock exactly the part that broke. 3. Check the build output where it matters: bundle size for a client dependency