Use lockfiles with purpose

CI uses a clean install from the committed lockfile, while library consumers resolve dependencies within the published ranges. This is a small part of a small slugify-title package that is tested locally, consumed from another project, and published safely, but the boundary it creates affects everything that follows.

The manifest declares allowed versions; the lockfile records one resolved graph with integrity data. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to delete the lockfile whenever an update behaves unexpectedly. It makes later failures harder to locate. Instead, commit and review lockfile changes, use clean installs in CI, and update dependencies in small evidence-backed batches. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Make dependency and version choices that communicate compatibility rather than merely making installation succeed. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Change one dependency, inspect the lockfile diff, reproduce the install in a clean directory, and record the tested graph. Hand the result to someone else and see whether the behavior is clear without an oral explanation.